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is to develop the As-Is process model, redesign the processes to increase efficiency and 
reduce costs, and develop a To-Be process model to improve the current business 
processes. Additionally, data flow diagrams of the To-Be processes are developed to 
assist in prototype design and implementation. The DoD standard IDEFO modeling 
technique is used for developing the process models. Implementation recommendations 
include: (1) adopting an ongoing reengineering strategy at MCI supported by the 
information systems ej'chitectures, methodologies and CASE tools, and (2) utilizing a 
single database to facilitate data sharing among MCI departments, streamline processes, 
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I. INTRODUCTION 



This chapter provides introductory information on the purpose and content of the 
thesis. It discusses the background and objectives of the research, the research questions 
and methodology used. It defines the scope of the thesis, and provides a list of acronyms 
used throughout. Finally, it outlines the content of each of the chapters. 

A. BACKGROUND 

The Marine Corps Institute (MCI) was established to "develop, publish, distribute, 
and administer distance training and education materials to enhance, support, or develop 
required skills and knowledge of Marines and to satisfy other training and education 
requirements as identified by the Commanding General, MCCDC" (MCI Mission, 1997). 
To accomplish its mission, MCI is organized into seven functional departments: education 
and operations, student services, information management systems, occupation specialty, 
professional military education, production, and logistics. 

The mission of the student services department is to support the enrollment, 
grading and management of the Marine Corps distance education and training programs. 

In support of its mission, the student services department employs an automated 
information system (AIS) to automate the actions required to support a student in the 
MCI correspondence program, maintain student records, and produce necessary 
management reports. The automated system, known as the Marine Corps Institute 
Automated InformatJ n System (MCIAIS), is a legacy system developed in the late 
1970's. It runs on a Hewlett-Packard 3000 mini computer running the MPE/iX operating 
system. MCIAIS is v ntten in HP proprietary language "Transact" and accesses a Turbo- 
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IMAGE hierarchical database. As is typical of many legacy systems, MCIAIS suffers from 
many shortcomings: 

• It has over 1 10 "spaghetti coded" programs that are difficult to maintain, 
modify, and upgrade. 

• It does not have underlying data or process models. 

• The programs have poor functionality, no statistical analysis capability, and 
limited "ad hoc" query capability. 

• It utilizes a "closed" non-relational database. 

• It does ncc support Graphical User Interfaces (GUI). 

In response to these shortcomings, MCI initiated a modernization project to 
redesign MCIAIS using "open" system architecture (both hardware and software). In 
addition, MCI is also reviewing and redesigning the business processes to better support 
its mission and current advances in training and education. MCI contracted with the Naval 
Postgraduate School to perform an analysis and develop a business process reengineering 
evaluation and migration plan proposal. A team of students was selected by Dr. Magdi N. 
Kamel, Ph.D. to conduct the evaluation and prepare the proposal. 

This thesis documents the process redesign portion of the Student Services 
Department (SSD) information system. The research was conducted from August 1996 
through August 1997 The complete project report is available as the following two 
technical reports. 

• NPS-SM-97-00 1 : Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, 
Preliminary Report (Kamel et al., 1997) 
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• NPS-SM-97-006: Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Final 
Report (Kamel et al., 1997) 

Other Naval Postgraduate School theses that cover related aspects of the modernization 
project include: 

• Data model design: A Relational Database Model and Data Migration 
Plan for the Student Services Department at the Marine Cotps Institute 
(Slaughter, 1997). 

• Architecture model design: A System Architecture and Migration Plan 
for the Student Services Department of the Marine Corps Institute (Evers 
Jr., 1997). 

• Prototype design: Development of Graphical User Intel face Standards 
and Prototype for the Student Services Department of the Marine Corps 
Institute (Hehe, 1997). 

B. OBJECTIVE 

The objective rf this thesis is to perform a detailed analysis of process 
requirements, review existing processes, develop the AS IS process model, redesign the 
processes to increase efficiency and reduce costs, and develop a TO BE process model to 
improve the current business processes using IDEFO models. Additionally, data flow 
diagrams of the To-Be AIS were developed to assist in prototype design and coding. 

C. RESEARCH QUESTIONS 

This research was focused on the following questions: 

• Can a process model be developed to reflect the current business process of 
the Student Services Department of the Marine Corps Institute (MCI)? 

• Can the business process of the Student Services Department of MCI be 
reengineered? 

• Can a process model be developed to reflect the reengineered business process 
of the Student Services Department of MCI? 
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• What BPR methodology is most suitable for reengineering the Student 
Services Department of MCI? 

• What CASE tool is most suitable for reengineering the Student Services 
Department of MCI? 

• Can a CRUD diagram be developed to support the BPR of the Student 
Services Department of MCI? 

D. SCOPE, LIMITATIONS, ASSUMPTIONS 

Prior to reengineering a large and complex organization, a business process 
reengineering methodology, a modeling technique, and supporting CASE tools must be 
identified. Once these are chosen, reengineering begins at the enterprise level and 
progresses down through the organization examining every process for ways to improve 
it. This thesis focuses on the process modeling, analysis, and redesign of the Student 
Services Department of the Marine Corps Institute. Other business areas at MCI identified 
in the enterprise analysis could be analyzed in a similar fashion in future efforts. 

E. RESEARCH METHODOLOGY 

Following a literature survey of business process reengineering methodologies, the 
methodology adopted for this research combines classic business process reengineering 
philosophy with information engineering techniques developed by James Martin. Before 
the data gathering stage of the project, considerable time was spent by the authors 
evaluating potential CASE tools. Once a CASE tool was chosen, more time was spent 
developing expertise with the tool’s features and capabilities. With the technical ground 
work laid, the authors each made three trips to MCI to interview personnel, observe daily 
operations, and gather documents. Personal visits were augmented by telephone 
conversations and the electronic exchange of model diagrams and associated information. 
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The information gathered was analyzed and structured by conducting the following 
activities: MCI enterprise analysis, business area analysis of the Student Services 
Department resulting in As-Is model development, logical redesign of the Student Services 
Department processes, To-Be model development, and SSD information system model 
redesign. The final result was a proof-of-concept prototype fully described in another team 
member’s thesis (Hehe, 1997). Complete model diagrams and documentation are 
contained in Naval Postgraduate School Technical Reports cited earlier. 

F. DEFINITIONS AND ABBREVIATIONS 

The following definitions and abbreviations are used throughout the thesis. 



ABC 


Activity Based Costing 


AIS 


Automated Information System 


ALMAR 


All Marine Message 


AVRS 


Automated Voice Response System 


BAA 


Business Area Analysis 


BPI 


Business Process Improvement 


BPR 


Business Process Reengineering 


CASE 


Computer Aided System Engineering 


CIM 


Corporate Information Management 


DoD 


Department of Defense 


FEA 


Functional Economic Analysis 


FP1 


Functional Process Improvement 


GUI 


Graphical User Interface 
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HQMC 

ICOM 

IDEFO 

IT 

LOGAIS 

MCC 

MCCDC 

MCI 

MCIAIS 

MCTFS 

MCU 

MIS 

MISD 

MOS 

NCO 

OSD 

PME 

PMED 

RUC 

SNCO 

SSD 



Headquarters, United States Marine Corps 

Input, Control, Output, Mechanism (acronym for all arrows on an 
IDEFO activity model) 

Integrated Definition for Information 
Modeling Language for Process Modeling 

Information Technology 

Logistics Automated Information System 

Major Command Code 

Marine Corps Combat Development Command 
Marine Corps Institute 

Marine Corps Institute Automated Information System 

Marine Corps Total Force System 

Marine Corps University 

Management of Information Systems 

Management of Information Systems Department 

Military Occupational Specialty 

Noncommissioned Officer 

Occupational Specialty Department 

Professional Military Education 

Professional Military Education Department 

Reporting Unit Code 

Staff Noncommissioned Officer 

Student Services Department 
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SSN 



Social Security Number 



UAR Unit Activity Report 

USMC United States Marine Corps 

G. ORGANIZATION OF STUDY 

Chapter II of this thesis is a description of the Marine Corps Institute, the 
problems with its current information system, and the overarching MCI modernization 
project. Chapter III discusses the information engineering methodology developed by 
James Martin and how it was applied to the MCI modernization project. Chapter IV 
discusses business process reengineering methodology and its application to reengineering 
the Student Services Department of MCI. Chapter V is a discussion of the IDEFO 
modeling technique, functional decomposition techniques, data flow diagramming, and 
CASE tool alternatives that were considered for use on this project. Chapter VI presents 
the enterprise analysis of MCI. Chapter VC details the business area analysis and the 
information system design portions of the methodology to the Student Services 
Department of MCI. Finally, Chapter VIII details recommendations for implementation 
and further research, and conclusions. 
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II. THE MCI MODERNIZATION PROJECT 

This chapter provides the details of the Marine Corps Institute (MCI) 
Modernization Project performed by the Naval Postgraduate School MCI Thesis Team. 
The chapter begins with a background of MCI, which includes a discussion of its history, 
mission, organization and description. The chapter introduces the MCI Automated 
Information System (MCIAIS) identifying the system interfaces, non-system interfaces, 
and known problems. The chapter presents the strategic plan for the enterprise-wide 
modernization effort of MCI. It then discusses the Naval Postgraduate School (NPS) role, 
the NPS MCI team members and their focused area of research. The chapter concludes 
with the benefits that MCI will reap from the project presented in a “process perspective”. 
A. MCI BACKGROUND 

MCI started as a school house in Quantico with part-time Marine instructors, but 
quickly developed into an accredited correspondence school. It was established to provide 
vocational training and personal development through part-time education during a period 
of the 1920s fraught with military indifference. A brief review of its history, mission, 
organization and description of services may shed some light on where its future should 
lead. (MCI Dream, 1997) 

1. History 

Lieutenant General John A. Lejeune is often referred to as “the greatest of all 
Leathernecks.” Among his noteworthy achievements during more than 40 years of service 
include the thirteenth Commandant of the Marine Corps, the first Marine to command an 
Army Division, a recognized strategist and effective leader (Lejeune, 1949). Lejeune also 
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established the Fleet Marine Force, formalized Amphibious Doctrine (Hough et al., 1997), 
and founded the Marine Corps Institute (MCI Dream, 1997). Lejeune left an indelible 
mark on the Marine Corps challenging leaders to develop their subordinates much like 
“fathers to sons or teachers to scholars”(Larson, 1996). 

Exhibiting that leadership against substantial resistance, then Major General 
Lejeune issued a Post Order on November 12, 1919, one month after assuming command 
of Marine Barracks Quantico, Virginia, establishing the first three vocational schools in 
the Marine Corps. The schools operated under the premise that normal military duties 
would be performed in the morning and vocational training would be available in the 
afternoon on a voluntary basis. The Vocational Training Schools Detachment at Quantico 
opened on January 5, i920. Courses like Automobile Mechanics, Band Music and Playing, 
Blacksmithing, Carpentry, Cooking and Baking, Drafting, Electrical Mechanics, Forestry, 
Gas Engine Design and Operations, Livestock, Painting, Plumbing, and Stenography and 
Clerical Work clearly demonstrated their utility during that era. (MCI Dream, 1997) 

MCI’s affiliation with correspondence courses began almost as soon as the 
Vocational Training Schools Detachment was established. The first Director, Lieutenant 
Colonel William C. "Bo" Harllee, traveled to Scranton, Pennsylvania and made an 
agreement with International Correspondence School (ICS) to use their courses for the 
instruction of Marine students. ICS reviewed ten percent of the completed examinations 
and Marine officer instructors reviewed the rest. This arrangement provided Marines, that 
satisfactorily completed a course, a completion certificate from ICS and co-signed by the 
Commandant of the Marine Corps. (MCI Dream, 1997) This accreditation and 
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certification philosopi y remains with MCI today, as an incentive and reward for Marines 
pursuing self-improvement 

The correspondence course aspect was first implemented in May 1 920 when 
enrolled students at Quantico were transferred to the USS HENDERSON and ordered to 
counter a potential uprising in Mexico. Lieutenant Colonel Harllee sent a school 
representative with course materials to the ship. The action demonstrated the need, and 
intent, to support Marine education using methods that do not infringe upon the Marine 
warfighting mission “in every clime and place.” The popularity of self-improvement was 
reflected in increased enrollments and a recruiting campaign that offered enlistees an 
assignment to Quantico where they could enroll in one of the schools. (MCI Dream, 1997) 

MCI has been moved and redesignated many times over the last 77 years. The 
Vocational Training Schools Detachment was forced to close the first month it opened 
because of an influenza epidemic. However, it reopened on the recognized founding date, 
February 2, 1920. The Vocational Training Schools Detachment at Quantico was officially 
designated as the Marine Corps Institute in July of 1920 and moved to Marine Barracks 
Washington, DC on November 10, 1920. In January 1926, military subjects were added to 
the available correspondence courses. In December of 1 946, it was organized under the 
Extension Division, Marine Corps Schools. In November of 1953, MCI was directed to 
discontinue its vocational courses, which were provided by the U.S. Armed Forces 
Institute, and focus only on military subjects. At this time, the arrangements with ICS 
ended. In June of 1977, the National Home Study Council gave accreditation to MCI. In 
October of 1980, the Extension School and MCI was consolidated and all Marine Corps 
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training and education correspondence courses became and the responsibility of the 
Director, Marine Corps Institute. MCI moved to its current location at the Washington 
Navy Yard in November 1993. Today, most MCI courses receive college credit through 
American Council on Education (ACE) accreditation. (MCI History, 1997) 

2. Mission 

MCI has two missions that govern their operations: education of Marines and 

ceremonial support to the Commandant of the Marine Corps. Early in its history, MCI 

administered and distributed correspondence courses developed by ICS. Today, in 

addition to administration and distribution, MCI must also identify and develop the 

courses that improve Marine proficiency. This shift in focus accounts for the evolution to 

MCI’s current mission (MCI In-Brief, 1996): 

To develop, publish, distribute, and administer distance training and education 
materials to enhance, support, or develop required skills and knowledge of 
Marines and to satisfy other training and education requirements as identified by 
the Commanding General, Marine Corps Combat Development Command. 

In the earliest days of MCI, the staff performed their primary military duties first 

and volunteered to assist in the vocational schools as a collateral duty. Today, MCI has a 

full-time staff, Marines and civilians, dedicated to course development and administration. 

Not to stray too far from their roots, the Marines have retained collateral military duties. 

This second mission of MCI results from its administrative assignment to Marine 

Barracks, Washington, DC (MCI In-Brief, 1996): 

To support the ceremonial mission of Marine Barracks, Washington, DC 

There are seven tasks that detail the execution of the two missions (MCI Mission, 1997): 
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1. Plan, develop, and administer a distance training program to increase the 
specialized skill proficiency of enlisted Marines. 

2. Plan, develop, and administer nonresident professional military education 
courses that parallel and supplement those resident courses provided by the 
Marine Corps Combat Development Command. 

3. Develop, print, stock and distribute the Marine Battle Skills Training 
Handbook and a performance test for use by commanders to measure 
proficiency in the Marine batde skills. 

4. Design, develop, revise, stock, and distribute training materials for those tasks 
contained in the Individual Training Standards system that are the 
responsibility of the unit commander to teach. 

5. Develop, print, stock, and distribute additional training materials as may be 
directed by the Commanding General, Marine Corps Combat Development 
Command. 

6. Provide personnel and administrative support as required for ceremonial 
purposes as directed by the Commanding Officer, Marine Barracks, 
Washington, DC. 

7. Provide automated information support to Marine Barracks, Washington, DC. 

These tasks specify Marines as the target student population. They also assign 

responsibility for the complete training package, from development through delivery, to 
MCI. These tasks also give an indication of the organizational requirements necessary to 
successfully carry out the seven mission tasks. 

3. Organization 

MCI is operationally controlled by the Commanding General, Marine Corps 
Combat Development Command (CG, MCCDC). Specifically, the Director, Training and 
Education Division, MCCDC, provides operational guidance to MCI. MCI receives 
technical direction on Professional Military Education course content from the President, 
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Marine Corps Univeisity. MCI is administratively controlled by the Commanding Officer, 
Marine Barracks, Washington, DC who is also the Director of MCI. (MCI In-Brief, 1996) 
Marine Barracks, Washington, DC is composed of a headquarters company, two 
ceremonial companies and the MCI company. The Barracks performs two evening parades 
every week during the summer and supports other ceremonial activities at the White 
House. The MCI Company of Marine Barracks provides escort and support services for 
the parades. The MCI company consists of six departments: Headquarters, Professional 
Military Education, Occupational Specialty, Logistics, Student Services, and Management 
Information Systems. (MCI In-Brief, 1996) 

The Headquarters Department has four sections that provide staff cognizance over 
MCI’s departments involved in the production and support of distance education and 
training materials. The Professional Military Education Department(PMED) provides 
courses based on Marine Corps resident PME school curricula or resident school 
prerequisites. The Occupational Specialty Department (OSD) develops and maintains 
military occupational specialty (MOS) related courses and MOS specific job aids. The 
Logistics Department (LOG) is responsible for the procurement, stock management, 
packaging, and distribution of MCI courses and training products. The Student Services 
Department (SSD) is responsible for the enrollment, grading, and student record 
administration of the distance education and training programs. The Management 
Information Systems Department (MISD) provides automated student administration and 
course material handling through MCI's automated information system (MCLAIS) and 
information systems support to MCI and the Marine Barracks. (MCI Mission, 1997) 
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4. Description of Services 

Since the days of General Lejeune, the Marine Corps has advocated personal 
development, and MCI has been focused on this objective. MCI has shifted from providing 
vocational and personal development courses for uneducated Marines in the early days to 
courses designed to improve the performance of today’s more educated Marines. MCI 
currently maintains six PME courses, 166 Military Operational Specialty (MOS) related 
courses, 16 MOS job '’ids, the Marine Battle Skills Training Handbooks and the Battle 
Drill Guide books. These materials are designed to enhance the student’s proficiency in 
their skill specialty, increase their awareness of Marine warfighting concepts and tactics, 
and prepare them for advancement to the next higher grade. (MCI Mission, 1997) 

The Marine Corps has emphasized the importance of completing MCI courses by 
granting enlisted Marines extra points toward promotion cutting scores. This incentive 
provides a more immediate benefit to an individual than college credit and education. 
(MC01400.32, 1989) 

Professional Military Education (PME) is intended to ensure that leaders have the 
knowledge required for their grade, and prepare them for the next higher grade 
(ALMAR26, 1996). Marine Corps University (MCU) was established to develop and 
implement PME programs (Mundy, 1994). The Commandant of the Marine Corps 
announced, with the All Marine message (ALMAR) 256-93, that promotion and retention 
would be linked to satisfactory completion of PME requirements (ALMAR256, 1993). 
MCU has established centralized resident PME schools and provides technical guidance to 
MCI on the development of non resident PME programs. 
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MCI programs were established as the baseline for PME programs, serving as 
either a substitute for resident programs or fulfilling prerequisites prior to acceptance in a 
resident program (ALMAR339-96). PME is so important that unless a Marine has 
completed the prescribed grade-specific PME program, resident or non-resident, he/she 
will not be considered “fully qualified” for promotion or retention (reenlistment). 
(ALMAR256, 1993) 

Whether the guidance was seen as a scare tactic or the result of a successful 
awareness campaign. Marines responded to the non-resident educational opportunities 
provided by MCI. On a monthly basis, MCI processes 50,000 enrollments, grades 80,000 
lessons and examinations, prints and mails 200,000 individual status documents, 56,000 
completion certificates and diplomas, 1,500 Unit Activity Reports, and produces 45 
internal management j eports. The management of this student record activity is the 
responsibility of the Student Services Department. (MCI In-Brief, 1996) 

B. MCI AUTOMATED INFORMATION SYSTEM 

The mission of SSD is to support the enrollment, grading and student record 
management of the Marine Corps distance education and training programs. In support of 
its mission, SSD employs an automated information system (AIS) to automate the actions 
required to support a student in the MCI correspondence program, maintain student 
records, and produce necessary management reports. (MCI Mission, 1997) 

1. MCIAIS System Overview 

The automated system, known as the Marine Corps Institute Automated 
Information System (MCIAIS), is a legacy system developed in the late 1970's. It uses a 
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Hewlett-Packard 300P mini computer running the MPE/iX operating system. MC1AIS is 
written in the Hewlett-Packard proprietary language, "Transact", and accesses a Turbo- 
IMAGE hierarchical database. MCIAIS maintains eight non-relational databases (MCI In- 
Brief, 1996): 

• ANSREF - contains all answers and references for every exam and lesson. 

• ARCHIV - contains student records that have been inactive for 13 months or 
more. 

• DBLOGS - contains the inventory records of courses and components. 

• MCEDB - contains all student course and information records. 

• MMSDB - an extract of the Marine Corps’ Manpower database that contains 
information on all active duty Marines. 

• MSEXAM - contains information on exam stock on-hand status. 

• REMPDB - an extract of the Marine Corps Reserve’s Manpower database that 
contains information on all class in reserve Marines. 

• S ALEDB - contains the raw data for the Statistical Analysis of Lessons and 
Exams Report (S.A.L.E. Report). 

These databases are only accessible from terminals within the Student Services or MIS 
Departments. 

2. System Interfaces 

System interface refers to the ability of two automated information systems to 
exchange data directly. While MCLAIS is a “closed” system, not originally designed to 
interface with external systems, the volume of transactions and the customer base has 
forced MCIAIS to be modified so that it can interact with certain external systems to 
reduce manual data entry. There are four systems with which MCIAIS interfaces: Marine 
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Corps Total Force System, the Marine Corps Unit Diary System, Conversant and the 
Logistic Automated Information System. 

The Marine Corps Total Force System (MCTFS) is the database maintained by 
Defense Finance and Accounting Center (DFAS) in Kansas City and contains all of the 
manpower information on Marines, both active duty and reservists. Specified MCTFS data 
elements are periodically downloaded to populate MCLAIS. Specifically, MCIDB and 
REMPDB are replaced by the download. This information is used by MCI for enrollment 
validation and material distribution. The interface is a labor intensive process that requires 
NATURAL computer language scripting and a lengthy daily download process through a 
host server at MCCT A in Quantico, Virginia. 

The MCTFS database is updated by individual Marine Corps units using an on-line 
system called the Un / Diary. Marine Corps units submit Unit Diary transactions to 
MCTFS. MCTFS screens the transactions and posts the valid transactions to the database. 

In the case of Unit Diary transactions that request MCI enrollment, disenrollment 
and completion, the validated transactions post to an advisory database. Transactions that 
fail screening post to the unit’s Unit Diary Error/Advisory Report. MCI downloads the 
validated transactions from the advisory database. This is also a labor intensive effort that 
requires scripting in the computer language ROSCOE. 

Once the Unit Diary transactions are downloaded, they must be formatted as input 
to MCIAIS. The transactions can error out when they run the program to post the 
transactions to MCIAIS. Each Unit Diary transaction rejected by MCIAIS must receive a 
response to notify the Marine Corps unit of the failed transaction. The unit then must 
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notify the student of the failed transaction, research the discrepancy, and resubmit the 
corrected transaction. 

MCI also maintains an Automated Voice Response System (AVRS) called 
Conversant. This system responds to a caller’s telephone keypad entry of social security 
number and course number and provides the caller with course status. This is an Oracle® 
database that contains copies of records for every student currently enrolled in an MCI 
course or program. The database is updated by during a weekly cycle that downloads, by 
overwriting, key data element to the Conversant database. 

The Logistics Department maintains a separate information system called 
LOGAIS. It provides automated management of the fiscal plan, organizational supply, 
logistic support and piocurement of MCI materials. It also provides certain inventory 
management functions. MCIAIS does not interface direcdy with LOGAIS for inventory 
management. MCIAIS creates mailing labels with material information and the student’s 
address for material distribution. Periodically, the inventory data is manually input into 
MCIAIS. 

3. Non-System Interfaces 

Non-System interface refers to interactions between an automated information 
system and another source that is not an automated information systems. This section will 
address six non-system interfaces that exist outside the MCIAIS: course and program 
development, course and program advertisement. Unit Activity Reports, telephone 
inquiries, U.S. mail, and electronic mail. 
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MCI courses and programs are designed in OSD and PMED respectively. All 
courseware is developed on PC’s in the respective departments. Each course is routed in 
paper form for editing and course content review. Once approved, the “proof’ is prepared 
and sent to the printer for reproduction. The new or revised course is added to the course 
catalog and appropriate data elements manually entered into MCIAIS pending receipt of 
materials. Students can be enrolled in the new course once the materials arrive and are 
stocked. 

Availability of new courses and revised courses must be advertised. Advertisement 
is done using three methods: MCI Course Catalog, MCI newsletters, and MCI mobile 
briefing teams. The MCI Course Catalog is revised and published, in paper form, annually 
making it an outdated tool for advertisement. MCI newsletters are published quarterly to 
update Marine Corps units on the availability of new or revised courses and other 
initiatives at MCI. MCI also forms a team that travels to major commands. The briefing 
teams meet with the Marine Corps unit commanders, training officers and training non- 
commissioned officers (NCO) to provide an update of current initiatives, training on 
administrative procedures and changes to old procedures, and to solicit input on MCI 
performance. The newsletters and the briefing teams, however, only reach a small fraction 
of the customer base. 

The Unit Activity Report (UAR) is designed to give the Marine Corps unit 
Commander visibility over the unit’s participation in MCI courses and programs. It 
contains a summary section with data compiled from enrolled students in each unit and a 
detailed transaction f^tory section for each student. MCI prepares a UAR for every 
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Marine Corps unit twice a month. One report is produced in paper form and mailed to the 
unit at the end of the month. Another report is produced in digital format and stored on a 
file server for units to download. 

The UAR also serves as a tool for reconciliation between the unit and MCI. The 
Marine Corps unit training NCO verifies that the unit’s enrollment record matches MCI’s 
record reflected in the UAR. The training NCO annotates any discrepancies or expected 
changes on the UAR and returns it to MCI. Annotations would reflect that a Marine has 
enrolled in a course that has not posted, been transferred, completed a course, disenrolled, 
or is awaiting completion certification. MCI manually processes the returned UARs by 
inputting the correcticns into the student’s record on MCLAIS. 

Telephone inquiries are handled by the Student Services Department. The 
Immediate Assistance section of SSD has a number of telephones staffed with clerks to 
answer inquiries. Non-Marine students, potential students and Training NCOs can contact 
MCI with their inquiries. MCI administrative procedures advise Marine students to 
address their questions to their unit Training NCO first. If unable to answer the question, 
the training NCO will contact MCI for resolution. This procedure is intended to minimize 
telephone calls to MCJ. 

MCI receives a large volume of U.S. mail on daily basis. This mail consists of 
enrollment requests, material requests, inquiries, disenrollment notification, returned 
UARs, and completed lesson or course examinations for grading. The mail must be 
opened, sorted and distributed. This is a manual and time consuming process. 
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Electronic mail is another method of interacting with MCI. The volume of 
electronic mail processed by MCI has grown significantly over the last two years due to 
expanded access to the Internet and increased unit access to the Marine Corps’ Banyan- 
vines network. Electronic mail traffic consists of enrollment requests, material requests, 
status inquiries, disenrollment notification, and returned UARs. 

4. Problems with MCIAIS 

As is typical o f many legacy systems, MCIAIS suffers from many shortcomings. It 
utilizes a "closed" non-relational database. It lacks well-defined procedures without 
underlying data or process models and the code has been poorly documented. It has over 
110 "spaghetti coded" programs that are difficult to maintain, modify, and upgrade. The 
programs have poor functionality, no statistical analysis capability, and limited "ad hoc" 
query capability. It does not support Graphical User Interfaces (GUI). These problems 
lead to further questions about data integrity and the credibility of the stored data. 

Internal problems within MCIAIS contribute to the loss of functionality within 
some of the databases. Many of the problems can not be repaired because of poor 
documentation and untraceable code within the legacy system. 

One example of lost functionality is the SALEDB, which provides the statistical 
analysis capability to determine the quality and effectiveness of test questions and answers. 
This capability provided critical information to the distance training instructors (DTI) 
which develop and revise the courses and examinations. 

The functionality of DBLOGS, the inventory management system, is also lost. As a 
result, the Logistics Department performs frequent cyclic inventories and manually adjusts 
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the on-hand quantity within MCIAIS to reflect changes. In the meantime, the Logistics 
Department switched to another logistics management system, ATLASS, that provides 
inventory functions in addition to functions not directly related to the inventory 
management of course materials. 

The interface with MCTFS poses an additional problem. The procedure for 
downloading Marine student information includes backing up the MCIAIS MCIDB and 
REMPDB databases and replacing them with the downloaded data. Any changes that 
were entered into the two databases are not reflected in the new data. This negates any 
Marine student address changes that have been updated via telephone, electronic mail or 
UAR since the last cycle. 

The UAR does not receive the attention it was designed to attract. Due to 
MCIAIS obsolescence, inaccurate reports have been historically produced. With over 
1500 UARs produced monthly, a lot of manual data entry is required to input the 
necessary changes. 

MCIAIS data accuracy was exacerbated by the UAR cycle time. As noted, student 
history data was not always accurate. A function of the UAR is to reconcile MCIAIS data 
with actual data from Marine Corps Units. The volume of corrections requiring manual 
entry into MCIAIS from UARs invariably did not get accomplished before the next UARs 
were distributed. Training NCOs became frustrated by MCI’s apparent lack of response 
and stopped returning UARs. Without corrected UARs, additional inaccuracies 
developed. Innovative training NCOs discovered that calling MCI and submitting 
corrections directly to MCI through an immediate assistance clerk was an effective 
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method to correct their unit’s records. This solution heightened telephone congestion 
problems. 

At a time when MCI was experiencing its greatest challenges with MCIAIS ’s 
ability to respond to the increased volume pressures as MCI courses and programs became 
requisite for promotion, the Marine Corps introduced Marine Mail. Marine Mail is an 
electronic mailbox set up for the Commandant to receive feedback about any subject 
directly from Marines. MCI problems were a common subject of Marine Mail. This type 
of visibility gave MCI an awareness of problems that they could not otherwise document 
and added impetus to find solutions. Many of the MCI problems can be attributed to the 
problems characteristic of legacy systems. 

One common problem identified was poor responsiveness and reliability when 
enrolling in MCI programs. In 1995, MCI initiated an enrollment process for active duty 
and reserve Marines using the Marine Corps unit’s Unit Diary system. This required 
detailed coordination with the programmers of MCTFS to establish prerequisite screening 
criteria and coded modules. Despite the MCTFS enrollment edits. Unit Diary transactions 
that passed MCTFS screening do not pass the MCIAIS screening. By shifting the data 
entry tasks to the unit, nearly 90 percent of enrollments are now automated. Research 
showed that it takes a unit an average of one week to process and run a Marine's 
enrollment request on the unit diary and another week for that request to be processed and 
posted on MCIAIS. There was not an effective or timely way for MCI to inform a student 
that an enrollment attempt failed. Other methods of enrollment, such as R-l card by mail 
or the monthly Unit Activity Report, are more reliable. Those methods are also slow 
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because of MCI manual data-entry processing time. This demonstrates the difficulty of 
programming between systems with a “closed” system. (ALMAR51, 1996) 

Another problem frequently identified was that delivery of MCI course materials 
was unreliable and not timely. A survey conducted by Columbia Services Group identified 
that faster service was what MCI students wanted most from MCI (MCLAIS Brief, 1996). 
Research attributed three causes to delivery problems. (ALMAR51, 1996) 

First, the vast majority of delays for material was because MCI did not have a valid 
address or location fc individual Marines. MCLAIS was using an outdated Reporting Unit 
Code (RUC) structure for Marine unit addresses instead of the current Major Command 
Code/ Reporting Uni: Code (MCC/RUC) structure used by the Marine Corps Total Force 
System (MCTFS). The MCTFS MCC/RUC is updated every time the unit’s address 
changes, as well as when a Marine is transferred. Since MCIAIS was using the RUC 
structure for mailing labels, which had not been updated for 18 years, materials were 
shipped to the wrong address. Consequently, MCI depended on the Commander's monthly 
Unit Activity Report (UAR) to identify a Marine's valid address. But only 60 percent of 
the units returned their UAR to MCI every month. (ALMAR51, 1996) 

The second cause was associated with Marine Corps unit mail handling 
procedures. MCI addressed course materials to the unit and the unit distributed the 
materials to the individuals. MCI research discovered that U.S. mail takes between three 
to twelve days to deliver course materials to units around the world. Delays beyond that 
were attributed to unit mail handling procedures. (ALMAR51, 1996) 
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The third cause of delayed course material delivery was attributed to replacement 
of out of stock materials. MCI found that it took up to two months to have course 
materials printed. This is compounded by the lost inventory management functionality of 
DBLOGS. There was not a reliable method to anticipate how soon the stock of a course 
would expire. Resolution of this problem within MCLAIS will require extensive analysis 
and coding to return the functionality of DBLOGS or establishing a direct system interface 
with LOGAIS. (ALMAR51, 1996) 

Yet another problem identified by Marine Mail was the delay in the delivery of 
final examinations. Administrative procedures required the student to complete the course 
lessons and/or a review exam and submit them to MCI for evaluation prior to issuing the 
proctored final exam. Once submitted, MCI would return the results and the final exam to 
the unit Training NO - ' to administer. The same mailing address problems associated with 
course materials also hampered final examination delivery. (ALMAR51, 1996) 

The last problem raised by Marine Mail was inconsistent posting of a course 
completion to the Marine’s official military record at Headquarters, Marine Corps. MCI 
research identified approximately 20 percent of course completions recorded in MCLAIS 
failed to post to the MCTFS record. When MCLAIS transferred data to MCTFS, data was 
lost. This was attributed to logic flaws within MCLAIS. This is another example of how 
undocumented “fixes” in a legacy system are difficult to trace or troubleshoot It also 
demonstrates the risk of a “closed” system interface with another system. (ALMAR51, 
1996) 
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MCI was established on a foundation of “vision” by far-sighted and resourceful 
innovators. Over the past ten years, the information system could barely support MCI’s 
primary mission of student record management, let alone accommodate changes necessary 
to keep pace with advances in distance learning. Innovation was spent on creating courses 
that the limited information system could support. The hallmark of vision was blurred and 
MCI’s reputation was tarnished. MCI was reacting, revising and distributing courseware 
that headquarters contrived, instead of designing innovative ways to educate Marines. 

C. MCI MODERNIZATION PLAN 

In response to the shortcomings, MCI initiated a modernization project to redesign 
and rewrite MCIAIS using "open" system architecture, both hardware and software. In 
addition, MCI began reviewing and redesigning their business processes to better support 
its mission and advances in training and education. 

1. Overview 

MCI’s modernization plan began with a requirements analysis that identified 
system design alternatives. A three-phase strategy was developed from the alternatives 
that planned for three phases of transition. 

The first phase focuses on transforming the information system from the current 
MCIAIS to a new M< TAIS-EI. This plans for the replacement of the “closed” legacy 
system with an open system, relational database using Fourth Generation Programming 
Language (4GL). The plan requires documentation of the data and process models. 
MCIAIS-D should maintain the same functionality of MCIAIS -I, but adds capability to 
send an electronic copy of diplomas to the Manpower Management Records Branch 
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(MMRB) of Headquarters, Marine Corps (HQMC), print mailing labels for individual 
course components, use “selected grade” of a Marine to determine enrollment eligibility, 
and has the ability to distinguish between different types of course media (i.e., paper, 
diskette, CD-ROM, etc.). MCIAIS-II should also perform statistical analysis of exams and 
ad hoc reporting for management and users. This phase includes plans to stand up a non- 
interactive Internet Home Page for MCI and to upgrade the Automated Voice Response 
System (AVRS) for enrollment without operator assistance. (MCI Redesign, 1997) 

The second phase plans for enhancements to MCIAIS-II. The customer should 
have the ability to enroll or inquire over the telephone AVRS or Internet accessing 
MCIAIS-II directly without a MCI operator. MCI should have an Automated Help Desk 
installed. This phase also includes the automation of warehouse operations and complete 
integration with MCIAIS-II. (MCI Redesign, 1997) 

The third phase is focused on development of Distance Learning Centers (MCI 
Redesign, 1997). MCI’s Distance Learning Center is connected to Training and Education 
Division’s distributee learning plan. Distributed learning is the use of instructional 
technology to increase an instructor’s effectiveness and provide a student-centered 
learning environment. The distributed learning plan is based on course modernization, end 
user computers, and a network infrastructure. (Eisiminger, 1996) 

2. NPS Role 

MCI contracted with the Naval Postgraduate School to lay the foundation with the 
modernization plan’s first phase. A team of NPS students was selected by Dr. Magdi 
Kamel to conduct a Business Process Reengineering evaluation and prepare a migration 
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plan proposal. Two reports, Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Preliminary Report, 
(Kamel et al., 1997) and Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Final Report, (Kamel 
et al., 1997), were prepared by the NPS MCI Team and delivered to MCI. 

a. Deliverables 

The objective of the NPS effort is to demonstrate a methodology that can 
assist MCI in transforming their current legacy information system into a modem 
environment that can take advantage of contemporary architectures and open 
technologies. Specifically, the NPS effort is to accomplish the following: 

1 . Perform a detailed data and process requirements analysis at both the 
enterprise and the Student Services Department business area levels 

2. Review existing SSD processes and develop a new model that includes 
redesigned processes to increase their efficiency and reduce costs 

3. Develop < target hardware, software, and network architecture based 
on open systems 

4. Develop a proof-of-concept prototype to validate the proposed 
methodology 

5. Develop a data migration and change management plan for the new 
system. 

The first report, Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Preliminary Report, 
(Kamel et al., 1997), develops an enterprise- wide architecture for the use of information 
systems in support of the MCI activities. The overall architecture is specified by defining 
three types of architectures: 
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1. Data Architecture: Defines the major kinds of data needed to support 
MCI’s business. IDEF1X modeling is used to represent data. 

2. Functional Architecture: Defines the major functions of the enterprise 
needed to manage the data. IDEFO modeling is used to represent this 
architecture. 

3. Technology Architecture: Defines the technology platforms needed to 
provide an environment for the applications that manage the data and 
support business functions. 

In addition to defining the above architectures, a set of matrices is 
developed showing the relationship between entities, functions, organization units and 
locations. The information provided by these matrices is intended to challenge 
management to think about its structure, mission, goals, and the information needed to run 
the MCI business. 

The second report. Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Final Report , (Kamel 
et al., 1997), conducts a detailed business area analysis of the Student Services 
Department (SSD) and Management Information Systems (MIS) functions. It presents a 
business area analysis by defining three types of models: 

1. SSD Data Model: Defines the major data entities, attributes and relationships 
used by SSD. IDEF1X technique is used to represent the data model. 

2. SSD Process Model: Defines the major processes needed to manage that data 
and support the operations of SSD. IDEFO modeling is used to represent the 
process model. 

3. SSD Technology Model. Defines the technology platform options required to 
provide an environment for the applications that manage the data and support 
the SSD business processes. 
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Specifically, the final report develops detailed data, process, and 
technology models for the SSD and MIS functions. The report also includes the associated 
design specifications for development of information systems applications to support 
Student Services, and a generated Oracle^ relational database schema with associated 
triggers. 

In addition to defining the above models, aproof-of-concept prototype of 
selected applications was developed to validate the methodology, refine resulting models 
and to establish graphical user interface standards for use across all MCI applications. 

b. Team Members and Research Topics 

The effort by NPS faculty and five students formed an integrated team to 
support the redesign of the Marine Corps Institute’s Automated Information System 
(MCIAIS) using contemporary architectures, methodologies and tools. In addition to the 
two reports submitted to MCI, four theses are also presented. 

Dr. Magdi N. Kamel is an Associate Professor of Information Systems in 
the Department of Sv stems Management. He has been at the Naval Postgraduate School 
since August 1988. His research interests are in the areas of application development, 
database management systems and information system architecture. Since joining the 
faculty at NPS, he has been the principal investigator on several research projects in 
application development, database management and expert systems. He is the author of 
numerous published papers on these subjects and a driving force in the NPS MCI Team 
activities. 



31 



Major Aaron T. Slaughter is a U.S. Marine Corps tank officer. He has a 
Bachelor of Arts in Political Science, presently in a Master of Science Degree program for 
Information Technology Management at the Naval Postgraduate School. He has been 
involved in several research projects in database management, application development 
and distributed support systems. He performed the data analysis and, working with the 
process model, produced the data model and data migration plan for the MCI 
Modernization Project. 

Major Clayton O. Evers Jr. is a U.S. Marine Corps communications officer. 
He has a Bachelor of Arts in Political Science, presently in a Master of Science Degree 
program for Information Technology Management at the Naval Postgraduate School. He 
has been involved in several research projects in network management, database 
management, application development and distributed support systems. He performed the 
system architecture analysis and, using the process model, produced the recommendations 
for the target architecture and the change management plan for the MCI Modernization 
Project. 

Commander (Select) Gerald L. Hehe is a U.S. Navy E-2C Naval Flight 
Officer. He has a Bachelor of Arts in Business Management, presendy in a Master of 
Science Degree program for Information Technology Management at the Naval 
Postgraduate School. He has been involved in several research projects in database 
management, application development and distributed support systems. He performed the 
user interface analysis and, using the data, process and information models, produced a 
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prototype to demonstrate the functionality of selected applications for the MCI 
Modernization Project. 

Lieutenant Colonel (Select) Kurt A. Baden is a U.S. Marine Corps CH- 
46E pilot. He has a Bachelor of Science in Aerospace Engineering, presently in a Master 
of Science Degree program for Information Technology Management at the Naval 
Postgraduate School. He has been involved in several research projects in database 
management, application development and distributed support systems. He performed the 
process analysis and produced the information system modeling effort for the MCI 
Modernization Project. 

Major Gerald A. Peters is a U.S. Marine Corps aviation supply officer. He 
has a Bachelor of Science in Political Science, presently in a Master of Science Degree 
program for Information Technology Management at the Naval Postgraduate School. He 
has been involved in several research projects in database management, application 
development and distributed support systems. He performed the process analysis and 
produced the process modeling effort for the MCI Modernization Project. 

3. Business Process Model Benefits 

The focus of this thesis is directed at the reengineering of MCI and the resulting 
process models. MCI has no prior model documentation on their information system or 
business processes. The documentation provided by the two reports and this thesis can 
facilitate communication between departments within MCI. The communication can 
develop a common understanding of department processes and their inter-relationship to 
each other. 
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Such documentation is useful for understanding the magnitude of change and 
identifies the tasks required to migrate to the new process. The documentation is dynamic. 
It will, and should, change to reflect continuous process improvements. It aids in 
recognizing previous problems and ensures those problems are not repeated in new 
processes. Documentation can provide a measure of the value of a proposed innovation. 
Data collection provides situational awareness. Given a process objective of reducing cost, 
for example, data collection would need to include the measurement of cost with which to 
compare. (Davenport, 1993) 

Since MCI has no documentation on their current system, the process model can 
serve as baseline documentation to support their current phase of modernization. It also 
provides a methodology that can be used with the subsequent phases of their redesign 
effort. The methodology employed was developed after a broad spectrum of techniques 
were evaluated and selected one as appropriate to fit MCI. 
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ID. INFORMATION ENGINEERING APPLICATION TO MCI 



This chapter describes the Information Engineering (IE) methodology and its 
relevance to the MCI modernization project. The first section briefly describes the entire 
methodology. Portions of the methodology that pertain to this thesis, enterprise analysis, 
business area analysis, and business system design are discussed in greater detail. Details 
of business process reengineering methodology, process modeling, CASE tools, and data 
flow diagrams are covered in later chapters. 

A. INFORMATION ENGINEERING METHODOLOGY 

James Martin originally conceived the information engineering methodology as a 
development tool for new information systems. Since IE provides a comprehensive 
framework for satisfy ing an organization’s information needs, the analytical techniques can 
also be applied to the reengineering of existing systems. IE encompasses all phases of life 
cycle development and implementation. IE methodology models the business process with 
three distinct but equally important models: a business data model, documenting the 
information and its source used by the business; a business process model, that 
decomposes the process into more detailed activities; and the interaction between the 
two, that defines the relationship between the data and the process models. Model 
development begins with analysis of business objectives and describes techniques to be 
applied that yield executable applications in the target environment. 

1. Information Engineering Overview 

Collectively, iiiformation engineering is an integrated set of tasks and techniques 
designed to support the systems development process. Integration is the crucial aspect that 
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accounts for successful outcome. Integration is fostered by a series of abstract layers 
devised to provide different views of the same business model. Within this information 
engineering framework, each layer serves as a platform from which to view the application 
systems in a different level of detail. If the system under evaluation is a new system, the 
path through the layers follows traditional system design methodology. However, if the 
methodology is applied to reengineer an existing system, entry may be made at the 
appropriate level and reengineering improvements are pushed through to the execution 
level. Figure 1 illustrates the IE layers and some typical paths through them. 
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'igure 1. The Layers of Information Engineering and Two Methods of Negotiating Them. 

After IEF™ Technical Description, 1992. 



The architectural layer models the organization at the highest level by examining 



the business strategy and business plan. It consists of three interlocking architectures: a 
data architecture, a process architecture, and a technology architecture. These three 



architectures can be represented as models and describe a high-level blue print for meeting 
the organization’s goals and objectives. (IEF Technological Description, 1992) 
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The conceptual layer models the business process and data. Process decomposition 
diagrams and a data model record the organization’s data and activity definitions, entities, 
and business rules describing the interdependencies. These models functionally decompose 
the concepts introduced in the architectural level and provide enough detail for analysis. 

The external layer models system behavior from the end user’s point of view. It 
contains specialized information about the conceptual layer of interest to the user, such as 
screen layouts and function key assignments. 

The implementation layer is a specialization of the external layer. It maps system 
characteristics to specific hardware and software requirements. 

The execution layer is the physical application of the model developed in the 
previous layers. 

The premise of EE methodology is a consistent framework on which many methods 

and techniques can be applied and coexist. Conceived with software automation tools in 

mind, information engineering methodology incorporates a systems development 

framework on which to build and possesses the following characteristics: a central 

repository of modeling objects with stored meanings and defined relationships; graphical 

techniques to represent modeling objects in diagrams; clearly identified relationships 

among diagrams; and correlated definitions of modeling objects across diagrams, offering 

multiple perspectives of the same object. 

The most important purpose of the information engineering methodology is 
to provide a framework within which an integrated set of software tools 
can exist in harmony. The framework describes the logical connections and 
constraints across the architectural, conceptual, external, implementation, 
and execution layers of the development life cycle. The task order, task 
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structure, diagramming conventions and semantics employed are secondary 
considerations. (EEF™ Technological Description, 1992) 

It is entirely acceptable for practitioners to build alternate task lists that conform to a 

different development paradigm and still function within the underlying framework. Points 

of departure generally hinge on a preference for some practice rather than a major 

difference in vision. (1EF™ Technological Description, 1992) 

2. Information Engineering Pyramid 

With the abstract framework established, Martin illustrates the information 
engineering methodology as a pyramid which has seven stages or levels: information 
strategy planning (ISP), business area analysis (BAA), business system design (BSD), 
technical design (TD), construction, transition, and production. Figure 2 illustrates the 
levels of IE. Detail increases and scope decreases as stages are accomplished. The 
methodology is iterative and stages 2 through 6 must be repeated for each of the business 
areas defined in stage 1. Stage 7 is not reached until the enterprise has been reengineered. 

Stage 1: Infonnation Strategy Planning (ISP) - During this stage, the 
organization is examir ed at the enterprise level to determine information needs and build 
an information strategy plan that is aligned with the business plan. Two models are 
created: a data model, indicating what data items are needed to perform the 
organizational mission, and a high-level model of the enterprise. The enterprise model is 
divided into business areas that support the organizational mission. 
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Figure 2. The Information Engineering Pyramid. After Martin, 1990A. 



Stage 2: Business Area Analysis (BAA) - An As-Is process model is developed 
using process decomposition techniques for one of the business areas. The model is 
technology independent. 

Stage 3: Business System Design (BSD) - During this stage, a business system is 
detailed within the chosen business area. Consideration is given to how the user will 
interact with the business system, however, the model remains technology independent. 
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Stage 4: Technical Design (TD ) - This is the first stage in which the hardware 
environment, operating system, and database management systems are examined. During 
this stage the BAA and BSD are tailored to the target computing environment 

Stage 5: Construction - During this stage, all executable applications are 
dev eloped. These include programs, databases, screen formats, and user manuals. These 
applications will enable the application system to operate on the target computer 
environment 

Stage 6: Tra-isition - During this stage, the new applications are installed in a 
production environment. This phased installation may involve replacing existing systems 
or portions of systems. 

Stage 7: Production - This is the final stage when all of the business areas have 
been reengineered and the enterprise realizes the full benefit of the improved business 
system. Execution of this final stage satisfies specific business needs identified during the 
initial stage. 

In addition to the seven stages, the pyramid is divided horizontally. The left side 
represents data and the right side relates to activities. The horizontal division within each 
of the stages is useful in dividing the required tasks among members of the reengineering 
team. For example, the left or data side of the pyramid is associated with the data 
modeler's tasks of identifying data subjects and entity types, modeling the relationships, 
and normalizing the entity records. Activity tasks such as business area identification, 
process decomposition, and matrix development fall on the right side. The first two stages, 
ISP and BAA. create a framework within which different teams build different parts of the 
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system at different times. To achieve consistency among separate modeling and 

development teams, the information collected at all levels of the pyramid is stored in a 

central repository called an encyclopedia. 

Building the framework in the top two stages takes some time. Typically, 
information strategy planning for the enterprise takes six months. Business 
area analysis takes four to six months for one area of the enterprise. 

(Martin, 1990B) 

The remaining five stages, BSD, TD, construction, transition, and production serve to 
design and implement the information system according to the plan devised during the first 
two stages. 

System construction does not wait until the framework is completely finished. 
Instead, a flexible prototype is quickly built which will allow quick retrofitting as the 
information engineering framework evolves. An objective of the IE methodology is to 
rapidly build systems that can be quickly modified by code generating CASE tools. 

B. THESIS METHODOLOGY 

While the MCI modernization project is concerned with all stages of the MCI 
enterprise, this thesis pertains only to the activity side, of the top three levels of the 
information engineering pyramid. Figure 3 illustrates these stages. Appendix A contains a 
detailed task list for both the data and activity sides. Three team member theses cover data 
modeling and execution of the remaining IE stages of the MCI modernization project. 
Integration of all team member’s efforts result in the complete modernization plan for 
MCI. The portions of the ISP and BAA stages of the information engineering 
methodology that pertain to process modeling include: enterprise level analysis of MCI, 
business area analysis of SSD, and design SSD To-Be information system model. 
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Enterprise 
Level Analysis 

1 . Identifcation of organizational units, 
locations, functions, and entity types 

2. Matrix Analysis 

3. Identification of Business Areas 




SSD Analysis 

1 . As-ls Process Model 

2. Reengineer As-ls Model 

3. To-Be Process Model 

4. Matrix analysis 

Information System 
Model 

1 . Data Flow Diagrams 

2. Process Specifications 



Figure 3. The Top Three Levels of the Information Engineering Pyramid, After Martin. 

1990B. 



C. ENTERPRISE LEVEL ANALYSIS OF MCI 

Enterprise level analysis results in an overview of the organization. This overview 

is used by top level managers and reengineering team to decide how to proceed with the 
modernization plan. The overview should not be too detailed. It is used to establish a 
broad overview in a short time. Detail will be added later during the business area analysis 



stage. 



The top level [of the pyramid] might be thought of as being like an author 
planning a book and creating its table of contents. He surveys the overall 
contents of the book and divides it into parts and chapters. He decides 
which chapters he should write first. Similarly, at the overview modeling 
stage he scopes out the overall structure and information needs of the 
enterprise, divides it into areas, and decides which area should first be 
analyzed in detail. (Martin, 1990B) 
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The overview information is stored in the CASE tool encyclopedia so it can be updated 
over time and used for further analysis as detail is added. 

To create an overview for the enterprise, data and process information must be 
integrated with the business strategy. The reader will recall that the information 
engineering pyramid is divided horizontally with data information on the left and process 
information on the right. Thus an enterprise level model is created when the data model 
information on the left and the process model on the right are mapped together with the 
strategic information. Mapping is achieved with matrices. The matrices are analyzed and 
clustered to define the business areas. There are three steps to this process: (1) 
identification of organizational units, locations, functions, and entity types, (2) matrix 
analysis, and (3) identification of business areas. 

1. Identification of Organizational Units, Locations, Functions, and Entity 
Types 

This first step documents the structure of the organization, identifies the functions 
and locations that perform the functions, and the major data entities. To successfully 
complete this step, it is important to identify individuals to interview and determine the 
extent of data and application sharing throughout the organization. Information is 
collected in several ways. Before the first interview, team members study the existing 
organizational structure, any existing business models, data dictionaries, task breakdown 
of the organization, and other documentation available about the organization. 

2. Matrix Analysis 

Once the information is gathered, matrices are created to help assess the extent of 
data and application interaction and validate the models for completeness. There are 
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several matrix combinations that can be generated from the gathered information. The four 
matrices most useful to the MCI modernization project are: organization versus location, 
organization versus function, location versus function, and data subject versus function. 
These matrices, as they pertain to MCI, are discussed in Chapter VI. 

Of the four matrices, the data subject versus function matrix is the most revealing. 
This matrix maps the data subjects, developed in the data model, to the functions of the 
enterprise. The matrix is created by listing the data subjects horizontally and the functions 
vertically. Each intersection is marked to indicate whether the data subject is created, read, 
updated, deleted, or archived by the functional area. The intersections are marked with a 
“C,” “R,” “U,” “D,” or “A,” respectively. For this reason the matrix is often referred to as 
a CRUD diagram. 

A CRUD diagram is useful for two reasons. First, several problems will be 
highlighted immediately. For example, there may be functions that do not use any of the 
data subjects or, a dara subject may be created by more than one functional area. 

Secondly, a CRUD matrix may be modified and clustered to reveal business areas. 

Clustering is a technique used to show which functions and data subjects fit 
naturally together. Before a CRUD matrix can be clustered it must be modified. First, the 
rows of functional areas are rearranged in life-cycle order (e.g., a course is first planned, 
then developed, managed, and finally archived). Next, the CRUD matrix is simplified and 
condensed into a "CR matrix." A CRUD matrix is converted to a CR matrix, by creating 
an identical function axis and data subject axis on a blank matrix. However, when filling in 
the intersections, all ' C,” "U,” "D,” and "A" entries from the CRUD diagram are replaced 
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with "C" entries. All 'R" entries from the CRUD matrix retain an "R" on the CR matrix. 
The CR matrix can now be clustered. 

Clustering arranges the order of the data subjects so that as they are read across 
the horizontal axis, the data subject that is created, updated, deleted, or archived by the 
first function (reading down the function axis) is moved to the left. Then the data subject 
created, updated, deleted, or archived by the second function is moved to the left. This 
continues for all data subjects. This process can be automated with some CASE tools. The 
resulting matrix has all the "Cs" arranged on a diagonal line running from the top-left to 
the bottom-right. The data subjects can now be grouped by boxing the clusters as shown 
in Figure 4. The boxes represent logical information subsystems with responsibility for 
creating and maintaining the data subjects. When data use falls outside of any box, the 
functions inside the box must access the data subject elsewhere, or the data must flow 
from one subsystem to another. These subsystems will later be defined as business areas. 

3. Identification of Business Areas 

As a result of clustering, eight business areas were identified for MCI: personnel 
administration, ceremonial support, program and course management, program and course 
development, student service support, warehouse and distribution, information systems 
management, and unit interaction. These business areas are described in Chapter VI. At 
this point business area analysis (BAA) techniques are applied to develop the process 
model and reengineer ihe business processes. 
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a Clustered CR Matrix. 



D. BUSINESS AREA ANALYSIS OF SSD 



The heart of business area analysis is development of the process model. The 
enteiprise level analysis resulted in business area identification. Once the business areas are 
identified, one of them must be selected as the first to be analyzed. If resources are not 
available to analyze them concurrently, the others will be analyzed in turn until the entire 
enterprise has been searched for reengineering opportunities. The selection of the first 
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business area for analysis is left up to the reengineering team and should be based on the 
following factors. (Martin, 1990B) 

• Demand: pressure of demand from senior end users for new or improved 
systems, assessed need, and political overtones 

• Organizational impact: number of organizations and people affected, whether 
the organization is geographically dispersed, and qualitative effect 

• Existing systems: adequacy or value of existing systems, relationship with 
existing systems, and estimated cost of future maintenance 

• Potential benefit: return on investment, achievement of critical success factors, 
achievement of goals, and solution to serious problems 

• Likely success: complexity, degree of business acceptance, length of project, 
prerequisites, and risks 

• Resources required: whether existing data or process models exist, whether a 
suitable CASE tool is installed, quality of available analysts, and funds required 

• Concurrent implementation: whether multiple BAA projects can proceed 
concurrendy, whether one project will train people who can quickly move onto 
other projects, and whether an existing data administration function has already 
done adequate data modeling 

Development of the process model is accomplished through functional decomposition. 
Process modeling and functional decomposition are discussed in Chapter V. 

1. As-Is Process Model 

The As-Is process model emerges from the process decomposition of each 
business area. Much of the material gathered during the enterprise level analysis (e.g., 

MCI department briefs, user interviews, training manuals, and management reports, etc.) 
is further scrutinized to define the lower level processes in detail. Business areas are 
broken down to their primitive level processes with the aid of a CASE tool which provides 
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a repository for all of the processes, their definitions and relationships. The process model 
includes both manual and automated processes. The As-Is model consists of three parts: 
(1) process node tree diagrams indicating process hierarchy, (2) process decomposition 
diagrams depicting the processes and the data or material they share, and (3) definitions of 
all of the symbols on each of the diagrams. IDEFO techniques are used for As-Is process 
modeling and discussed in Chapter V. 

2. Reengineer the SSD As-Is Process Model 

Once the As-hs process model is created and validated by the process owner, the 
reengineering principles that best fit the situation, are applied. The goal of reengineering is 
to reorganize the organization around the key processes performed by the business. Most 
reengineering methodologies investigate ways to eliminate non-value-added processes, 
minimize redundant data entry and storage, integrate or combine similar processes, 
implement data sharing, and automate manual processes. Business process reengineering 
methodologies are discussed in Chapter IV. 

3. To-Be Process Model 

The To-Be process model is the result of reengineering the As-Is process model. 
The To-Be model is often a streamlined version of the As-Is process model, but in all 
cases represents a mui e efficient reincarnation of the former organization. Like the As-Is 
process model, the To-Be process model is modeled using an appropriate modeling 
technique and consists of three parts: (1) process node tree diagrams indicating process 
hierarchy, (2) process decomposition diagrams depicting the processes and the data or 



48 



material they share, and (3) definitions of all of the symbols on each of the diagrams. 
IDEFO techniques are used for To-Be process modeling and discussed in Chapter V. 

4. Matrix Analysis 

Matrix analysis techniques are again applied to validate the process and data 
models and lay the ground work for the next level of the information engineering pyramid, 
business system design. Once the To-Be process model and the data model are complete, 
a matrix is created that shows the relationship between business processes and data model 
entities. The matrix is first generated as a CRUD, converted into a CR matrix and then 
clustered as described earlier. The matrix analysis is used for three purposes: (1) to ensure 
that all of the data model entities are created, read, updated, deleted, and archived by the 
process model, (2) to ensure that the data model contains only the entities required by the 
process model, and (3) to support the clustering of related processes into groups that 
reveal candidate applications to be distributed to the workstations in the overall 
client/server system. Five applications were identified for SSD during this step: student 
servicing, unit servicing, grading, registrar, and executive summary information. 

E. SSD TO-BE INFO SYSTEM MODEL 

The information system model represents that portion of To-Be process model that 
transfers or transforms data within the system. Manual processes are not included. Like 
the case of the As-Is and the To-Be business models, a visual presentation is more useful 
than a verbal description. IDEFO can be used for modeling the information system. 
However, a more common form of information system model depiction is with a logical 
data flow diagram (D C D). The information system model integrates the data model details 
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with the automated processes and presents them in a form that can be interpreted by a 
programmer developing code for a prototype system. The information system model 
consists of three parts: (1) DFDs depicting information system process decomposition, 

(2) definitions of all of the symbols on each of the diagrams, and (3) process specifications 
at the primitive process level. Data flow diagramming is discussed in Chapter V. 

F. CASE TOOL 

Information engineering is made practical by the use of a CASE tool. It is 
important to choose a tool in which planning, analysis, design, modeling, and construction 
modules are integrated and share the same encyclopedia. The metadata in the encyclopedia 
resulting from the ISP study is a valuable asset and should be updated periodically. As the 
strategic goals or objectives of the business change, the information in the encyclopedia 
should also be changed. In this way, the business model remains current and available for 
periodic review. The ISP should be reviewed periodically along with goals, problems, 
critical success factors, and technology impact effects to ensure they remain in synch with 
the strategic vision and business plan. A suitable CASE tool facilitates this analysis. CASE 
tools are discussed in Chapter V. 
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IV. BUSINESS PROCESS REENGINEERING METHODOLOGY 



This chapter presents a discussion and comparison of business process 
reengineering (BPR) methodologies and their relevance to the MCI modernization project. 
The first section introduces business process reengineering concepts. The second section 
briefly describes four prominent BPR methodologies. The third section compares the 
methodologies. Finally, the fourth section evaluates each of the BPR methodologies in the 
context of MCI and selects the BPR methodology best suited for reengineering the 
Student Services Department of the Marine Corps Institute. 

A. REENGINEERING METHODOLOGY OVERVIEW 

There are many accepted reengineering methodologies. Some of the more notable 
methodologies include: Process Innovation, Business Process Improvement, Business 
Process Redesign, and Business Process Reengineering. Each methodology’s approach 
differs by the degree c f change and duration of implementation. Although the techniques 
of execution vary, the goal is ultimately the same: reorganize the organization around the 
key processes performed by the organization. Most reengineering methodologies 
investigate ways to eliminate non-value-added processes, utilize information technology to 
minimize redundant data entry and storage, integrate or combine similar processes, 
implement data sharing, and automate manual processes. 

The generic term business process reengineering has evolved from Michael 
Hammer’s original radical overhaul methodology to include the full spectrum of many less 
severe process improvements. Figure 5 illustrates the fact that as the process modifications 
become more signifn ant there is a also an increase in project cost. 
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Figure 5. BPR Spectrum. 



expectations, risk of failure, and time to complete the venture. A survey of four 
methodologies provides a broad spectrum of possibilities and capabilities for reengineering 
the Student Services Department at MCI. Four methodologies are briefly discussed in the 
succeeding section. While each methodology is unique in its detailed execution, they all 
share common elements: organizing, team building and planning, documentation of the 
current process, analysis, redesign, information technology application, implementation 
and, monitoring. 

B. REENGINEERING METHODOLOGY REVIEW 

Four BPR methodologies were reviewed as candidates for the MCI modernization 
project: Hammer and Champy’s Business Process Reengineering, Thomas Davenport’s 
Process Innovation, H. James Harrington’s Business Process Improvement, and DoD’s 
Functional Process Improvement (FPI). Each is briefly described below. The order in 
which the methodologies are discussed represent the operationalism of the BPR process. 
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beginning with Hammer and Champy’s principles and progressing to the Functional 
Process lmprovemei; designed to be implemented with an integrated suite of CASE tools. 
Details of each methodology can be found in Appendix A. 

1. Hammer and Champy 

Michael Hammer was the first to popularize the concept of reengineering when he 
wrote the article, “Reengineering Work: Don't Automate, Obliterate" (Hammer, 1990) for 
the Harvard Business Review. Hammer maintains that traditional “total quality” 
approaches to process improvement are insufficient in today’s competitive market. 
Hammer’s point is actually a caution to all reengineering projects not to blindly apply 
technology before analyzing the business process first. Misapplication of information 
technology is often a hindrance and Hammer counters that an organization must first 
recognize its problen • and then “dramatically” overhaul the way it does business. This 
dramatic overhaul requires a completely fresh approach in order to accomplish the 
objective. All preconceived notions of organizational structure, decision making, and final 
product delivery must be ignored and a new way of doing business must be conceived. 

In 1993, Hammer co-authored Reengineering the Corporation with James 
Champy. In the book they formally defined reengineering as “the fundamental rethinking 
and radical redesign of business processes to achieve dramatic improvements in critical, 
contemporary measures of performance, such as cost, quality, service, and speed” 
(Hammer and Cham,./, 1993). Reengineering requires the organization to consider the 
final product of its e; 1 orts, and include information technology as a requirement of 
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success. While information technology can be very useful, it should not be applied 
haphazardly. 

Hammer and Champy’s approach to reengineering is to start with a clean slate and 
concentrate on goods and services producing processes, seeking to provide orders-of- 
magnitude level improvement as opposed to incremental improvements through total 
quality management principles. Their approach stresses the need for competition analysis, 
customer feedback, and strong organizational desires to succeed. While they lay out the 
principles of reengineering and provide numerous examples of corporations that 
successfully diagnosed and corrected their own quality and market performance 
deficiencies, Hammer and Champy shy away from individual business task analysis and do 
not provide many concrete techniques that reengineering teams can apply to their own 
organizations. While the case studies illustrate the successful application of Hammer and 
Champy’s reengineering principles, each of the corporations is different and the individual 
techniques applied by each to turn itself around may not be appropriate for another. 

2. Thomas Iiavenport 

Thomas Davenport’s Process Innovation concentrates on process analysis. Process 
Innovation is dividec nto five phases: identify processes for innovation, identify change 
levers, develop process vision, understand existing processes, and design and prototype 
the new process. Davenport’s five phases guide the reengineering team through a 
thorough search for processes in need of streamlining, with particular interest in the 
application of information technology. Like Hammer and Champy, Davenport uses a 
“clean slate” approach and stresses that incremental improvements to business processes 
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are not enough in today’s intensely competitive global markets (Davenport, 1993). 
Davenport’s goal is to make the organization more profitable, efficient and more satisfying 
to customers by any means, be it organizational structure changes, application of 
information technology, or changing the very nature of the business. Davenport’s 
methodology contains more techniques than does that of Hammer and Champy. 

Phase I, identify processes for innovation , begins with developing a list of the 10 - 
20 key organizational processes, defining these processes and noting any interdependence 
between them. Each process on the list is then examined to determine its strategic value to 
the organization’s goals, health, and the political and cultural pressures associated with it. 
Phase I concludes with a prioritized list of candidate processes for reengineering. The 
process that is most central to the company’s overall goals, most problematic, and has the 
political backing of organization leaders should be the first entry on the list. The other 
processes will follow as resources permit. 

Phase n, identify change levers, surveys the potential technological and human 
opportunities available to change the process. An important aspect of this phase also 
examines potential constraints and barriers to process change. Examples of constraints and 
barriers include, “strict hierarchical structures, cultures unreceptive to innovation, and 
general organizational rigidity or inability to accommodate change” (Davenport, 1993). 
Both opportunities anti constraints are considered and the best change lever is selected. 

Phase ID, develop process vision, includes identification of measurable objectives 
and characteristics of the process, and formulation of specific process attributes. First, the 
organization’s current vision and business strategy are compared to the company’s desired 
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future state. Second, customer feedback is collected to correlate effort and results. The 



process is then benchmarked against similar processes of competitors. New performance 
measures are then created for the process that will satisfy current customers, take the 
organization where it wants to be, and meet or exceed competition quality. 

Phase IV, understand existing processes, documents and models the existing 
process to use as a baseline for evaluating proposed process improvements. To accomplish 
this, the current process is assessed with the improved process criteria developed from the 
previous phase. Shonoomings not only in process work flow, but organizational structure, 
information infrastructure, and employee skill levels are identified and short term 
improvements are explored. 

Phase V, design and prototype the new process, is the implementation stage. 
Design alternatives are enumerated. After assessing each alternative for feasibility, risks, 
and benefits, the preferred redesign is prototyped. Following successful prototype 
evaluation, a migration strategy is developed and the improved process is implemented. 

3. H. Janies Harrington 

H. J. Harrington’s five phases of Business Process Improvement (BPI) are less 
radical than that of Himmer and Champy, or Davenport and reflect more of a total quality 
approach. Harrington theorizes that management spends too much time correcting 
problems that should not have occurred in the first place. Business managers should now 
be responsible for developing business and manufacturing processes that work error-free. 
Existing business processes should be redesigned to error-free standards. Throughout the 
entire methodology, Harrington emphasizes the necessity of proper training for those 
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executives and employees who perform the analysis and process reengineering. Harrington 
addresses five phases: organizing for improvement, understanding the process, 
streamlining, measurement and control, and continuous improvement. 

Harrington’s objective of Phase 1 , organizing for improvement, is to ensure 
success by building leadership, understanding, and commitment (Harrington, 1991). 

During this phase, the organization appoints an executive improvement team to act as a 
steering committee and a business process improvement czar to be responsible for 
overseeing the project through to fruition. This high-level management group determines 
the scope of the project, establishes the level of organizational commitment, and appoints 
the process improvement team (PIT). Members of the PIT are appointed from the 
departments who own the processes being reengineered. The PIT members carry out the 
modeling, analysis, and reengineering of each business process. 

Phase II, understanding the process, is the data collection and modeling stage of 
the methodology. PIT members examine business strategy, interview customers, define 
and model business processes with flow charts and documentation to develop what is 
known as an As-Is be dness model. 

Phase III, streamlining, is where the actual reengineering takes place. PIT 
members seek to ider dfy process improvement opportunities by eliminating bureaucracy 
and no-value-added activities, simplifying the process, reducing process time, upgrading 
equipment, standardizing data, or automating activities (Harrington, 1991). 

The objective of phase IV, measurement and control, is to implement a system to 
control the process for ongoing improvement (Harrington, 1991). Once the process has 
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been reengineered, process targets are established by which performance of the improved 
process will be measured. 

Phase V, continuous improvement , embraces total quality principles by 
continuously monitoring the improved business process for continued excellence. Periodic 
examination of the process performance is benchmarked against the best practices in 
industry' and if need be, the process improvement cycle is repeated. 

4. DoD Functional Process Improvement (FPI) 

The functional process improvement program was established in January 1992 by 
the Corporate Information Management (CIM) Information Technology Policy Board to 
assist Department of Defense agencies in making improvements to their business 
processes. FPI is the most comprehensive of the BPR methodologies discussed thus far. 
The CIM mandates that FPI create As-Is process models with the IDEFO technique. The 
FPI also evaluates potential process improvement alternatives using activity based costing 
techniques. During the final phase of the FPI methodology, a functional economic analysis 
(FEA) is prepared by the reengineering team for the decision makers. A FEA is a 
“business case” that presents the alternatives in business and economic terms more 
understandable to the majority of senior executives. 

FPI attempts to integrate six underlying principles: strategic/business planning, 
activity modeling, data modeling, activity based costing, economic analysis, and best 
business practices. Six major steps describe the FPI methodology. The methodology is 
further subdivided into enabling tasks described in Appendix A. 
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a. Underlying FPI Principles 

Strategic/Business Planning - Strategic planning provides a set of business 
goals and defined requirements expressed in terms of customer needs within the context of 
agency mission, vision, values, and beliefs. A strategic plan defines what an organization is 
all about, who it will serve, what needs it will fulfill, and under what terms it will operate. 
A unique requirement of the governmental hierarchy is that the strategic plan must be 
consistent with those of higher authority, and no element of the strategic plan can conflict 
with the mission, vision, values and beliefs expressed by higher authority. On the other 
hand, business planning provides a set of business objectives with appropriate performance 
measurements and a comprehensive list of required output product and service features 
that will meet the customer needs defined in the strategic plan. The business plan should 
focus on what the organization will do to satisfy the goals, needs and requirements 
expressed in the strategic plan. 

Activity Modeling - Activity modeling is a technique used to understand 
the business process. Process decomposition is used to decompose a process into 
activities. The result is a multi-level diagram representing the business process with all of 
the inputs, outputs, controls, and mechanisms affecting the final product or service. This 
final model is referred to as the As-Is process model. The As-ls model will be 
reengineered to become the To-Be process model. The To-Be model will eventually be 
used to develop a prototype and implement the improved business process. 

Data Modeling - Data modeling is a technique for systematically describing 
what information the organization needs to perform its business process. Like activity 
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modeling, an As-Is model is first produced, describing the current data environment. The 
As-Is data model is then analyzed and compared with the As-Is process model to ensure 
that all required data is included and conversely, that no redundant or unused data is 
collected or maintained. A data model shows all of the entities, attributes, and 
relationships among the entities. Entities are objects which an organization values enough 
to keep data about. Attributes are the data items recorded about the entities. Relationships 
between and among entities are often expressed as business rules. To ensure compatibility 
with the process modeling technique, FPI mandates that data modeling be done with the 
IDEF1X technique. A complete description of data modeling is contained in A Relational 
Database Model and Data Migration Plan for the Student Services Department at the 
Marine Corps Institute (Slaughter, 1997). 

Activity Based Costing - Activity-based costing (ABC) is a technique that 
allows unit cost determination of producing goods and services. ABC is an extension of 
activity modeling. IDEFO activity modeling is designed to record activity cost data. Unit 
cost figures resulting from ABC are the basis for economic analysis. 

Economic Analysis - Economic analysis provides the capability to assess 
the costs and benefits associated with each process improvement, taking into account the 
life cycle characterist’cs of each investment. The As-Is process model is used as a baseline 
by which all competing alternatives are compared. Economic analysis presents the decision 
data in equally valued dollars (taking the time value of money into consideration), as well 
as the risks associated with making decisions about future conditions and performance. 
Economic analysis is presented as a FEA. 



60 



Best Business Practices - Benchmarking proposed process improvements 
against recognized industry leaders is the technique used to ensure the proposed 
improvements are up to par with the best alternatives available. 
b. FP / Methodology 

The fu actional process improvement methodology consists of these steps: 

define, analyze, evaluate, plan, approve, and execute. Each of the steps integrates the 

underlying principles to cover the entire BPR project from start to finish. 

Define - During this phase, a framework is established by defining baselines, 
objectives, and strategies for the process. Activity and data modeling begin in 
preparation for the analysis phase from which to begin process improvement. 

Analyze - This phase proposes the improved process alternatives. The As-Is 
process model is analyzed to examine all processes that make the current process 
more effective and efficient. ABC data is gathered and modeled for each activity of 
the process decomposition. 

Evaluate - Alternatives are compared against the baseline processes in terms of 
both function and cost. 

Plan - A migration plan is developed for each of the contending improvement 
alternatives. The plan should be comprehensive and cover the impact on costs, 
benefits, risk, and the effect on the organizational structure. 

Approve - Pertinent data from the definition, analysis, evaluation, and planning 
phases are assembled for presentation of each of the improvement alternatives to 
the highest level executive decision makers. This presentation is in the form a 
Functional Economic Analysis (FEA). A FEA is similar to a traditional economic 
analysis. Both evaluate the economic feasibility of a project using classic economic 
analysis techniques. The primary difference between them is scope. While an 
economic analysis usually covers a single initiative an FEA covers the life-cycle 
aspects and the overall effect of the intended change on the entire organization. 

Execute - Once approved, the new system is implemented in accordance with a 
DoD-wide technical integration and migration strategy. 
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C. SELECTION CRITERIA 



The selection of a reengineering methodology is based on perceived conditions of 
the business environment and often depends on the degree of interest by senior 
management and the amount of risk the organization is willing to take toward 
implementing redesign efforts. Understanding the business environment and the 
organization will aid the reengineering team in the selection of a methodology. Before 
selecting a methodology, the organization and analyst must consider reengineering 
categories, reengineering ideals, reengineering principles, and reengineering roles. 

1. Reengineering Categories 

Reengineering methods can be grouped into three categories: crisis, goal oriented 
and life-cycle. (Koulopoulos, 1995) 

Crisis reengineering is a response to pressures, internal or external, which 
necessitate a change to current business operations. This type of redesign is less likely to 
follow a formal methodology. High level sponsorship within the organization is not 
required because change must be effected regardless of the method. Crisis reengineering 
carries a high degree of risk since it is often unplanned. 

Goal oriented reengineering seeks to substantially change the fundamental 
business objectives. This strategy radically transforms the organizational processes by 
disregarding all present processes and designs how the company will function in the 
future. This method requires high level sponsorship due to the inherent risk of eliminating 
familiar processes and implementing futuristic procedures. 
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Life-cycle reengineering is strategic and continuous. Incremental changes are 
made constantly to alter the business direction. The redesign effort establishes a baseline 
assessment of how business is conducted. Managers then use metrics to establish value for 
each task and examine alternatives that will improve the processes. Improvements, radical 
or conservative, to current processes are made where necessary. This category of 
reengineering requires a high-level champion to provide continuity and ensure adequate 
program funding. Life-cycle reengineering is considered the safest for organizations 
without the resources or the capacity to assume the higher levels of risk inherent in the 
other categories. 

2. Reengineering Ideals 

Hammer and Champy list four themes that are preeminent in successful 
reengineering efforts (Hammer and Champy, 1993): process orientation, ambition, rule- 
breaking, and creative- use of information technology. All four reengineering ideals have 
application to the MCI modernization project. However, due to cultural and budgetary 
constraints, reengineering at MCI was narrowly focused within the Student Services and 
Information Systems Departments, the primary creator and administrator of the data. 

Process Orientation - Organizational perspective is influenced by the management 
theory in vogue. The industrial age focused on task organization and work simplification 
in an assembly line. The information age centered on gathering and distributing 
information. The current trend in “down-sizing” or “right-sizing” leads to a perspective 
focusing on processes and process improvement. 
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Task-oriented jobs in today’s world of customers, competition, and change 
are obsolete. Instead, companies must organize work around process. To 
achieve significant productivity and quality improvement, an entire process 
must be analyzed, not just the work steps within a department of an 
organization. (Hammer and Champy, 1993) 

Ambition - AU business processes within an organization must be considered 
candidates for reengineering. Reengineering teams must be ambitious, seeking innovative 
ways to improve all business processes. No area should be protected from this scrutiny. As 
noted, only one third of the whole business would be considered for reengineering as part 
of this modernization project. 

Rule-breaking - Business rules are efforts by an organization to standardize 
operating procedures. Reengineering teams should consider new ways to significantly 
improve productivity without allowing existing rules to limit their consideration of 
alternatives. This requires a commitment by management to sever their reliance on the 
comfort of established procedures. Considerable effort by MCI was put into eliminating or 
streamlining the business rules and regulations attached to student’s course enrollment. 
This reduction in business rules simplified prototype coding and will simplify 
implementation coding and code maintenance in the future. 

Creative use of information technology - Information technology (IT) and its rapid 
advances play a significant role in BPR. Thomas H. Davenport identifies nine areas where 
BPR can benefit from IT (Davenport, 1993): 

1 . Automation - IT can automate tasks reducing redundancy of data entry 
improving quality, integrity and speed. 

2. Information - Electronic transfer of information and documents via 
telecommunication systems or networks decreases process completion time 
and facilitates enhanced work coordination. 
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3. Sequence - IT, using databases and groupware, allows parallel work 
accomplishment, improving the sequencing of tasks and decreasing overall 
business cycle time. 

4. Tracking - IT enables the close monitoring of process objects and their 
completion status. 

5. Analysis ■ The data manipulation, storage and presentation capabilities of IT 
allow for the critical analysis of processes and their supporting information. 

6. Geography - Telecommunications networks allow the sharing and transfer of 
information between geographically dispersed organizations. 

7. Integration - Database and groupware technologies allow multiple personnel to 
work together on a single project. 

8. Intellect - IT, such as expert systems, allow the capture and preservation of 
corporate knowledge and procedures. 

9. Disintermediation - Electronic data interchange decreases the requirement for 
person-to-person interactions and reduces the number of people involved in a 
process. 

3. Reengineering Principles 

Reengineering principles represent the best reengineering practices collected from 
the industry and distilled to their very essence. Principles are not limited to manual and 
automated processes but may also be applied to the cultural aspect of reengineering. 

Process Prim ivies - In any organization, there will be manual and automated 
processes subject to improvement. These principles are general and can guide the 
reengineering team (Hammer and Champy, 1993): 

• Combine several jobs into one to involve fewer people in the completion of a 
process. 

• Let the worker make decisions. 

• Perform the steps of a process in a natural order. 
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• Designate a person who will be responsible for controlling and improving each 
process. 

• Create multiple versions of a process. Each version should be dependent upon 
a particular outcome of a decision made by the person performing the task. 

• Perform work where it makes the most sense. 

• Reduce checks and controls on work. Only perform tasks that add value to the 
overall process. 

• Provide a single point of contact to business customers. 

Russ Linden delineates these additional principles (Linden, 1993): 

• Substitute parallel for sequential processes to decrease business cycle time. 

• Capture information once, at the source. 

• Bring “downstream” information “upstream” so that all required information 
for the entire process is gathered and entered into the system at the start. This 
will decrease data gathering and communication times. 

• Ensure a continuous flow of value-adding activities. Get rid of tasks that do 
not produce something of value to the customer. 

• Organize around outcomes, not functions. Ensure there is an important 
business reason for conducting a process or task. 

• Redesign first, then automate. Do not automate first and simply speed up a 
faulty procedure. 

• Know why a piece of paper enters the system. Substitute technological 
interfaces where face-to-face interactions are not required. 

Cultural Principles - Effective application of these principles during the 
reengineering process will result in the transformation of numerous aspects of the 
organization (Hammer and Champy, 1993): 

• Jobs change from simple tasks to multidimensional work. 

• Organizational structures change from hierarchical to flat. 
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• Managers change from supervisors to coaches, shifting emphasis from 
oversight and control to facilitator, enabler and educator. 

• Executives change from scorekeepers to leaders. 

• Values change form protective to productive. 

• People’s roles change from controlled to empowered. 

• Job preparation changes from training to education. 

• Focus of performance measures and compensation shifts from activity to 
results. 

• Advancement criteria change from performance to ability. 

4. Reengineering Roles 

Finally, the organization itself determines the outcome of any reengineering effort. 

A BPR consultant may be used to advise the organization on how to accomplish a 

reengineering project but it is the personnel within the organization who actually 

reengineer the business processes. Employees know and understand the business and 

these personnel fill key roles during the redesign project. (Hammer and Champy, 1993) 

Leader - The leader is an executive level manager with oversight responsibility. 
The leader must be able to influence reluctant employees to embrace the change 
program. The leader is the steward, creating the corporate vision while ensuring 
managerial and financial continuity. 

Steering committee - The steering committee is a group of senior managers who 
define the reengineering strategy, determine project priority, allocate resources and 
assist the reengineering teams problem resolution. 

Reengineerin.-. czar - The reengineering czar is the organizational expert on 
reengineering procedures and tools and must be able to oversee the project from 
beginning to end. The czar must support each process owner and the reengineering 
team as well as coordinate all reengineering activities. The czar is the technical 
interface between the reengineering team members and the leader. (Hammer and 
Champy, 1993) 
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Process owner - The process owner is a senior leader responsible for the effective 
and efficient function of a particular business process. The owner provides the 
reengineering team with process information during the change effort and becomes 
responsible for its implementation and continued optimization. 

External consultant - The use of an external consultant during a reengineering is 
often recommended for several reasons. It may be difficult for managers inside the 
enterprise to take a detached view point. A skilled external consultant can often 
clearly see and diagnose problems in an organization that would go unnoticed by a 
manager busy with day to day operations. Consultants are also useful as experts in 
reengineering methodology application, prototype development, data and process 
modeling, critical success factor analysis, and other aspects of reengineering that 
organic organizational mangers may not possess. Not only is it important for a 
consultant to have technological expertise but they should also exhibit the personal 
relationship skills necessary for them to integrate with top management and the 
reengineering team. Together they will accomplish the reengineering. 

The actual reengineering process is performed by the reengineering team. The 

team should be comprised of personnel from various functional areas, especially one 

experienced in current information technology advances. There should be members from 

outside the process under review to provide objectivity and interface awareness. Process 

analysis, modeling, and redesign are time consuming efforts and should be done as quickly 

as possible to avoid “paralysis by analysis.” The team members should be assigned to the 

project on a full-time basis, but not less than 75% commitment level is required. (Hammer 

and Champy, 1993) 

D. BPR TECHNIQUE COMPARISON 

All of the surveyed methodologies are similar in composition, but differ in 
sequence and level of detail during execution. Figure 6 places the surveyed methodologies 
on the BPR spectrum introduced earlier in the chapter. Each of the methodologies has 
individual merits but there is not one methodology perfectly suited for every situation. For 



68 



Process Business Process Business Process 



1MPROV 


EMENT 

FPI 

Harringto 


REDE 

n 


SIGN REENGI 

Hammer & Champy 
Davenport 


MEERING 






MINOR 

modifications 


MODEST MAJOR 

modifications modifications 



[INCREASING cost, time, expec tations risk_IH^> 

Figure 6. BPR Spectrum with Selected Methodologies in Place, 
comparison. Table 1 summarizes the main stages of each methodology. Each has 
strengths, weaknesses, and other characteristics that are worthy of analysis before 
selecting the most appropriate methodology for the MCI modernization project. 

The common thread running through all of the methodologies is that each of them 
accomplishes the basic steps of traditional system development stages: planning, analysis, 
external design, internal design, and construction. The difference in the methodologies is 
the degree of detail they prescribe. Table 2 compares the methodologies and serves to 
highlight the similarirVs and differences between them. 

The methodologies can be grouped into two categories of reengineering: radical 
and incremental. Radical reengineering “...means disregarding all existing structures and 
procedures and inventing completely new ways of accomplishing work (Hammer and 
Champy, 1993). Incremental reengineering, considered by Hammer and Champy to not 



69 



Hammer and 
Champy 


Davenport 


Harrington 


DoD 


Develop Business 
Strategy 


Identify Processes 
For Innovation 


Organizing For 
Improvement 


Define 


Identify Change 
Levers 


Identify Change 
Levers 


Understanding 

Process 


Analyze 


Identify 
Reengineering 
Teams and Leaders 


Develop Process 
Visions 


Streamlining 


Evaluate 


Identify Processes 
with Change 
Potential 


Understand Existing 
Processes 


Measurement And 
Control 


Plan 


Implement the New 
Process 


Design And 
Prototype 


Continuous 


Approve 


j The New Process 


Improvement 


Execute 



Table 1. BPR Methodology Summary. 



even qualify as “reengineering,” is based on the total quality approach introduced by 
Demming in the 1 950s. Incremental methodologies analyze existing processes and seek to 
improve productivity with more conventional, less radical changes to organizational 
structure and application of information technology. Both radical and incremental 
reengineering methodologies prescribe process improvement but differ in the scope of 
their methods. 

The methodologies of Hammer and Champy, and Davenport both fall into the 
radical methodology category. The methodology of Hammer and Champy is the most 
radical and the least detailed. Hammer and Champy strive for dramatic improvement and 
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“dramatic improvement demands blowing up the old and replacing it with something new” 
(Hammer and Champy, 1993). 

While Hammer and Champy fail to provide techniques that reengineering 
practitioners might use to accomplish the task, their methodology has been distilled into 
the principle pillars that all other reengineering methodologies are built on. Hammer and 
Champy’ s intended audience is the chief executive level and is full of motivating rhetoric 
and successful examples from the business world. At the CEO level, detailed knowledge 
of techniques are not necessary. One of Hammer and Champy’s reengineering principles is 
that reengineering projects often fail due to lack of top management support. Hammer and 
Champy serve to educate and motivate, top executives empowering them to ask questions 
and champion their o vn reengineering cause. The importance of IT application into the re- 
invented corporation t ad reengineering team is also emphasized. 

Davenport also advocates IT application and provides more detail than Hammer 
and Champy but not enough for a reengineering team to rely on for complete 
reengineering. Like Hammer and Champy, Davenport’ process innovation expects 
reengineering to net substantial increases in productivity and profit by starting with a 
“clean slate” and effecting a one-time, top-down, broadly cross-functional fundamental 
change to the way the organization conducts business (Davenport, 1993). Davenport 
suggests detailed techniques to be used for analyzing business environment, identifying 
candidate processes for innovation, gathering performance objectives, and applying IT 
solutions. Davenport' s methodology briefly mentions the role of top management during 
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reengineering and list industry success stories but does not elaborate on techniques to 
foster reengineering leadership or organizational reengineering roles. 

The risk of failure for such radical and sweeping changes during a short time to an 
organization is much higher than the less radical, total quality based incremental process 
improvement methodologies: business process improvement, and functional process 
improvement. Both of these methodologies are rich in practical techniques that can be 
readily applied by reengineering practitioners. 

Harrington’s methodology offers comprehensive coverage from planning to 
implementation. He furnishes guidance on how to organize the organization, select teams, 
collect and analyze data, reengineer the process, and continue monitoring the improved 
process after implementation. Harrington emphasizes the importance of training the 
reengineering team and executive leaders prior to beginning the project to reduce the risk 
of failure. Specific techniques are augmented by examples of analytical methods (e.g., 
graphs, charts, matrices, etc.) to assist the practitioner with decision making throughout 
the process. It is implied that these tools could be implemented with computer software 
but Harrington does not specifically address the use of any CASE tools. 

The last methodology surveyed, functional process improvement relies on CASE 
tools for smooth operation. The use of CASE tools that model processes in IDEFO, linked 
with ABC analyzing software are mandated as is software specifically developed to 
prepare a FEA. 

In typical Department of Defense fashion, the functional process improvement 
model with its 25 steps prescribing still more detailed and specific tasks could be labeled 
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the most comprehensive methodology. Like BPI, FPI offers comprehensive coverage from 
planning to implementation. Flexibility is limited, however, by the hierarchical constraints 
inherent in government bureaucracy. For example, FPI planning tasks include briefing the 
upper echelon about reengineering theory, principles, risks, and benefits but do not 
mention reengineering team composition or reengineering leadership roles. FPI presumes 
that the innate hierarchy will suffice. FPI data gathering and analysis techniques focus on 
activity based cost accounting principles and culminates with the presentation of the FEA 
to the top level of the nierarchy. Once the ultimate decision as to which alternative to 
choose is made, the innate hierarchy again is presumed to oversee the execution stage. 

This methodology appears to be driven by the process and all reengineering decisions 
made exclusively in terms of lifecycle costs with inadequate attention to implementation 
and monitoring. Although the methodology is inflexible, the concept is sound and is well 
supported in terms of software support and training. 

E. REENGINEERING METHODOLOGY SELECTION 

Central to the success of the modernization project is selection of a suitable BPR 
methodology. Of the many methodologies available four candidates were evaluated. When 
assessing a methodology’s fit to the MCI modernization project, each of the BPR 
methodology selection criteria, discussed in the second section of this chapter, was 
considered in the business environment context at MCI. 

1. Reengineering Methodology Characteristics 

Before selecting the reengineering methodology best suited for the particular 
business environment it is useful to specify criteria with which the reengineering team can 
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compare competing methodologies. The DoD Manual for BPR identifies the following 
characteristics of an effective methodology for change management (DoDInst 8020. 1-M, 
1993): 



Completeness - The methodology must provide steps that direct a business process 
improvement procedure from establishment to implementation. 

Applicability - The methodology must be able to be used on any process of the 
business. 

Friendliness - The procedure must be easy for all personnel, including non- 
technical workers and managers, to learn and understand. 

Consistency - :t must be the only methods used to conduct reengineering within 
the organization. This will allow in-house reengineering expertise to be developed. 

Supportable - The reengineering procedure must include detailed documentation, 
training courses and project management tools. 

Successful - The methodology should have a record of success and these cases 
should be available to guide the actions of the reengineering team. 

Documentable - The procedure must produce process documentation as it is used. 

Enabled by Tools - The method must be supported by automated tools that help to 
ease the reengineering workload and enable process documentation and 
measurement. 

2. BPR Technique Selection for MCI Modernization Project 

As initial information was gathered about the current information system and 
business process at MCI, research was initiated into the most appropriate business process 
reengineering methodology, modeling technique, and supporting CASE tool. After 
considering all of the factors, there was no one single BPR methodology that exactly fit 
the MCI situation at face value. Elements of each were used in the end and will be 
discussed in detail in Chapter VII. 
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The methodologies of Hammer and Champy, and Davenport were both ruled out 
as the business culture at MCI would not support sweeping changes to their current 
business process. Although Hammer and Champy do not offer specific techniques, their 
reengineering principles and ideals are crucial to successful reengineering. Davenport 
provided sound guidance at the strategic vision level, establishing a need for 
reengineering, and determining where in the organization to look, but lacked techniques 
for conducting the reengineering. 

In contrast, DoD’s functional process improvement provided too much detail. It is 
not necessary to conduct all of the FPI tasks to successfully accomplish organizational 
reengineering. FPI was not selected due to the distinct lack of accurate cost data available 
at MCI necessary to drive the ABC cost models. 

The authors fe t that Harrington’s business process improvement methodology, 
based on continuous process improvement and offering comprehensive and detailed 
techniques, provided the best fit for MCI modernization. Combining Harrington’s BPR 
methodology with Martin’s information engineering offers a strong overall methodology 
for analyzing MCI at the enterprise level. Additionally, the integrated philosophy espoused 
by information engineering offered more flexibility and potential for application to the 
remaining business processes at MCI not included as part of this research. 
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V. TECHNIQUES AND TOOLS 

This chapter discusses in greater detail some of the techniques and tools used 
during the analysis of previous chapters. The first section discusses process modeling, 
functional decomposition, and IDEFO modeling methodology. The second section 
discusses data flow diagramming and its relevance to the business system design level of 
the information engineering methodology. The final section discusses CASE tool 
evaluation and selection for the MCI modernization project. 

A. ACTIVITY MODELING 

There are many different modeling and diagramming techniques in use for process 
modeling. Techniques have been borrowed from finance, software or systems engineering, 
and product engineering. Examples of modeling techniques include: entity-relationships 
(ER), structure charts, flow charts, data flow diagrams, and IDEF modeling. Many of the 
techniques are variations of one another and may share semantic structures but vary in 
their graphic presentation to convey different aspects of the organization to different 
audiences. For instance, a business may be modeled with an entity-relationship diagram for 
the database designer while the same business may be presented to the programmer as a 
series of data flow diagrams. Different views of the business require different modeling 
techniques. 

1. Process Modeling and BPR 

The main objective of business process reengineering is to transform an 
organization around the key processes performed by the business to improve productivity 
and efficiency. Since BPR was popularized in the early 1990s by Michael Hammer, many 
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similar but competing BPR methodologies have been published. Although they vary in 
scope and complexity, the common thread among them is the use models to represent the 
interdependent and often complex relationships that exist between the elements of a 
modem organization (i.e., business rules, processes, stakeholders, inputs and outputs). 
Effective BPR can not be conducted without first understanding the organization. Models 
enable understanding by structuring business information in a way that individual 
components can be visualized and interdependencies can be analyzed. 

Models are more than diagrams. While the diagram of a model may depict a 
process as a series of activities with inputs and outputs, many details about the process 
need to be defined. Information such as the activity’s name, definition, owner, inputs, 
outputs, etc. are stored in a central repository known as a data dictionary or data 
encyclopedia. The data contained in a data encyclopedia is also known as metadata. This 
collection of metadata ensures consistency throughout the modeling process. 

2. Process Modeling Technique 

A process or activity model is a tool used by an analyst to understand a business’ 
current environment and provides a framework with which a business may be 
systematically dissected and analyzed with an eye to improve the business process in some 
way. “A process... is a specific ordering of work activities across time and place, with a 
beginning , an end, and clearly identified inputs and outputs: a structure for action” 
(Davenport, 1993). These activities are the building blocks of process models. The 
process model makes business area analysis possible. 
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A completed process model graphically depicts the individual steps, information, 
and resources needed to perform a business process as well as how sub-processes may be 
interdependent. Additionally, activity modeling is an important step in validating 
information requirements within an organization, because the activity model shows the 
relationship between an activity and the information that it uses or produces. This level of 
detail is necessary to conduct effective redesign analysis. 

A process or activity model is used to describe business activities and their 
relationships. It is hierarchical and starts with a high-level view of the process. The model 
then breaks a process into sub-processes. Sub-processes may also be divided into sub-sub- 
processes and so on providing increasing levels of detail. This technique is known as 
functional decomposition. For this reason, individual activity model diagrams are often 
known as decomposition diagrams. Functional decomposition is further explained in the 
next subsection. 

The IDEF series of modeling methodologies offer easily interpreted diagrams, data 
sharing capabilities between data and process models, and a standardized format well 
suited for computer aided analysis. IDEFO was mandated by MCI for process modeling, 
and IDEF1X was mandated for data modeling. IDEF modeling techniques are the 
modeling standard for agencies within the Department of Defense. 

IDEFO is one of the most useful process modeling techniques and was used for this 
analysis for two reasons. First, IDEFO is the modeling technique mandated by the 
Department of Defense (DoD) business process reengineering initiative, an agenda item of 
the Corporate Information Management (CIM) program. CIM was initiated in the early 
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1990s when Paul Strassmann was the director of the Defense Information Systems Agency 
(DISA). CIM’s goals were to maintain DoD mission capabilities despite downsizing and 
budget reductions by implementing improved business processes which: (1) are enabled 
by technology, (2) substantially increase productivity, (3) decrease cost, and (4) do not 
sacrifice quality. Secondly, the IDEFO modeling technique has unique and powerful 
features not found in any other single process modeling technique. Figure 7 is an example 
of a decomposition diagram using the IDEFO modeling technique. 




Figure 7. IDEFO Activity Diagram. 



3. Functional Decomposition 

The process model is developed using a technique known as functional 



decomposition. Functional decomposition is a method of moving from the functional 
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areas at the enterprise level through the business areas and finally exploding the business 



processes to their primitive level. Figure 8 graphically depicts functional decomposition. 
The figure is useful in helping the reader to distinguish between several related terms. 

Functional areas are defined at the enterprise level and exist to define the business 
functions of the organization as a whole. Functional areas are the very essence of the 
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Figure 8. Functional Decomposition. After Martin, 1992. 
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business and refer to major areas of activity, but do not include sufficient granularity for a 
detailed analysis. For example, when developing the MCI enterprise model, seven 
functional areas were identified that represent the business activity of MCI (described in 
Chapter VI j. These include headquarters support, course management, course 
development, student servicing, information systems management, warehouse and 
distribution, and unit interaction. These functional areas define the business of MCI but do 
not provide enough detail to describe the detailed processes performed by MCI personnel. 
Functional areas are subdivided into business functions. 

Business functions are a collection of activities which together support a functional 
area by furthering the mission of the organization. A business function is continuous and 
ongoing and is concerned with what is to be done but not how. For example, four business 
functions support iht functional area student servicing, identified in the MCI enterprise 
business model. These business functions include customer servicing, student activity 
transactions, grading, and registrar servicing. Like the functional areas, these business 
functions lack sufficient detail for analysis. Business functions are subdivided into business 
processes. (Martin, 1990B) 

A business process is a specific act with a definable beginning and end, identifiable 
inputs and outputs, and is performed repeatedly. It is at this level that sufficient detail is 
added to the model to allow for analysis and reengineering. Complex processes may be 
further subdivided into simpler processes until a primitive level process is reached when 
any further decomposition would yield no greater understanding of the process. 
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Enterprise le' . 1 modeling tends to emphasize the terms functional area, business 
function, and business process. Once the business area analysis stage begins, functional 
areas are known as business areas, business functions are known as functions, and business 
processes become processes. The terms are often used interchangeably in reengineering 
text books. The term activity is a generic term often substituted for a process at any level 
of analysis. The similarity of the terms can be confusing. Table 3 maps the term to the 
information engineering stages. 



Enterprise Analysis 
(Information Engineering 
Stage 1) 


◄ ► 


Business Area Analysis 
(Information Engineering 
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functional area 


of the enterprise is 
known as 


business area 
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of the enterprise is 
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function 
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of the enterprise is 
known as 
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Table 3. Terminology Map Between the First Two Levels of IE. 



4. Evaluation of IDEFO Technique 

IDEFO was developed in the late 1970s as a by-product of the U.S. Air Force’s 
Integrated Computer Aided Manufacturing (ICAM) Program. The Integration Definition 
for Information Modeling (EDEF for short) technique resulted in several graphical 
modeling conventions, each used for a different purpose. For example, IDEF1X is used 
for data modeling anu IDEFO is used for functional modeling. Although IDEFO was 
originally used to document manufacturing processes and to show what information and 
resources were needed in each step, it was proven to be well suited for modeling any 
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application that uses information and resources. IDEFO modeling has been used in both 
government and private industry since 1985 and has become the DoD standard for process 
modeling. 

An IDEFO model represents business activities from a functional point of view. 

The model depicts how the activities interrelate, the inputs used by each activity during 
activity execution, and the output of each activity. The model itself is hierarchically 
composed of decomposition diagrams and the data repository which contains the 
definitions of, and relationships between, each of the activities, inputs, outputs, controls, 
and mechanisms. The acronym ICOM is used collectively to describe any of the possible 
information flows into or out of an activity: inputs, controls, outputs, or mechanisms. 

The IDEFO activity modeling technique represents the business process with four types of 
diagrams in addition to the metadata encyclopedia. 

1. Node trees diagrams graphically portray activities in a hierarchical form. 

2. A context diagram is a single diagram that illustrates the highest level activity. 

3. Decomposition diagrams represent the detailed sub-processes of an activity. 

4. FEO (For Exposition Only) diagrams are used to focus attention on a 
particular portion of a node tree, context, or decomposition diagram and do 
not have tc conform to all of the modeling rules. 

IDEFO process models integrate smoothly with activity based costing techniques 
to provide a powerful all-encompassing model to accelerate the reengineering process. 
ABC is a powerful tool for measuring business performance, determining the business 
process costs, and as a means of identifying ineffective and inefficient activities. Because 
the IDEFO activity model provides a structured approach detailing an activity’s 
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information input and output, the addition of process cost details (e.g., the cost of labor, 
materials, and overhead) associated with accomplishing the task, the value of each 
individual task’s contribution to the whole can be assessed. Activities that are not cost 
effective, or add no value to the business product, but do incur costs, become early targets 
for elimination when streamlining the business process. 

5. IDEFO Terminology and Constructs 

This section presents a brief overview of IDEFO terminology, symbols, and 
constructs to assist the reader in interpreting IDEFO diagrams. Figure 9 illustrates the 
IDEF symbols. 
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Figure 9. IDEFO Symbols. 



Activity - a function or process that must be accomplished and produces output. 
Activities are represented by a box, are numbered hierarchically, and are named 
with a verb phrase to describe what they do. Activities are numbered hierarchically 
with each decomposition retaining the parent’s number followed by a decimal 
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point and its own number beginning with one. (e.g., the parent activity numbered 
A- 1.2 could have two children numbered A- 1.2.1 and A- 1.2.2). 

Primitive Activity - an activity that is not decomposed further (i.e., has no children 
activities). In a decomposition diagram, a primitive level process is distinguished 
by a small diagonal slash, known as a leaf, in the top left corner of the activity box. 

Context Diagram - the model diagram representing the highest level activity or 
process. It contains only one activity box with the model subject as its name. It is 
the starting point for the decomposition of the entire model. The context diagram 
is numbered A-0. 

Decomposition - a method of moving from general to specific through 
decomposition diagrams by separating activities into components. 

Decomposition Diagram - a diagram representing a more detailed look at an 
activity. The top level provides overview while each succeeding diagram provides 
greater detail of the previous diagram. Decomposition diagrams are numbered 
hierarchically with each subsequent diagram retaining the parent’s number 
followed by a decimal point and its own number beginning with one. (e.g., the 
parent diagram numbered A2 would have a child diagram numbered A2.1) 

Parent Diagram - any decomposition diagram that contains an activity that has 
been decomposed (i.e., has children diagrams). 

Child Diagram - any decomposition diagram that represents the details of a parent 
activity. 

Node Tree Diagram - shows the activities arranged hierarchically in a tree 
structure. 

Input (Arrow) - represent data or objects consumed by the activity. Input arrows 
always enter the diagram from the left and terminate at an activity. 

Output (Arro* ) - represent data or objects produced by the activity. Output 
arrows always exit an activity and exit the diagram to the right. 

Control (Arrow) - represent data or objects that specify conditions that must exist 
for the activity to work correctly. Control arrows always enter the diagram from 
the top and terminate at an activity. 

Mechanism (Arrow) - represent data or objects that assist the activity in 
performing its task. Mechanism arrows always enter the diagram from the bottom 
and terminate at an activity. 
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Call (Arrow) - a type of control arrow that calls on another activity. Call arrows 
always exit an activity and exit the diagram at the bottom. 

B. DATA FLOW DIAGRAMS 

Data flow diagrams are another representation of the process model. Specifically, 
DFDs are used to depict the information system model. Once the process model has been 
reengineered, the business system designer must develop a prototype. Input and output 
information depicted on the activity model is too abstract to aid the programmer in 
prototype development and coding. A programmer must retrieve the data from the 
database tables, manipulate it according to the process model and business rules, and 
finally, route the output data to another process or database table. For this reason even the 
lowest level process decomposition diagram is of little use to the programmer because the 
process model does not indicate the precise source or destination of the data. A DFD 
maps the data sources and sinks (i.e., database tables) to the data elements that flow to 
and from each process. Data flow diagrams serve as the interface between the data 
modeler, process developer, and GUI/prototype designer. 

Data flow diagrams start at the highest level with a context process designated as 
the context diagram. Diagram level zero then decomposes the context diagram into major 
activities. Decomposition continues to a level that allows the programmer to map 
individual data elements to specific process activities. Figure 10 is an example of a 
primitive level DFD showing the information system designer which data elements are 
required and from which database table they originate. 
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Figure 10. Primitive Level Data Flow Diagram. 



1. Similarities Between DFDs and Activity Models 

Because activity models and data flow diagrams represent the same process and 
data elements, there aie similarities between them. Properties that process models and 
DFDs share include: functional decomposition, hierarchical numbering, and parent/child 
relationships. 

Functional Decomposition - The functional decomposition concept is the same. In 
DFDs a context diagram, numbered “0” forms the basis for the system and all 
decompositions stem from it. 

Hierarchical Numbering - The hierarchical numbering scheme for DFDs is similar 
to that used in the activity models. DFD process numbers are prefixed with a “P.” DFD 
data store numbers are prefixed with a “D.” DFD processes are numbered hierarchically 
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with each decomposicon retaining the parent’s number followed by a decimal point and its 
own number beginning with one (e.g., the parent process numbered P-1.2 could have two 
children numbered P-1.2.1 and P-1.2.2). Primitive level processes are denoted with a “P” 
suffix (e.g., P-2.3.2. IP). 

ParentIChild Relationships - Child processes and data stores are considered to be 
part of their parent and serve to reveal more detail. For example, it is assumed that when 
referring to a parent data store all information contained in its children is included. 

2. Data Flow Diagram Symbols 

Although DFDs are a similar to the process decomposition diagrams of the As-Is 
and To-Be IDEFO models they use different notation. There are three data flow 
diagramming symbol conventions in contemporary use: Gane and Sarson, Yourdon and 
DeMarco, and Ward and Mellor. Each depicts data flows within a information system 
using different symbology. Data flow diagrams for this project are created in the Gane and 
Sarson convention. DFDs depict only four symbols: (1) external entity, (2) process, (3) 
data flow, and (4) data store. Figure 1 1 depicts Gane and Sarson DFD symbols. All DFD 
objects are defined in the central data repository. 

External Entity! Source or Sink (not to be confused with entity in the data model 
terminology) - a data source from outside the information system that either sends data to 
the system or receives data from the system. It is not considered to be part of the 
information system a 'though it interacts with the system. Outside entities are labeled with 
a noun. They may be duplicated on different diagrams and are depicted on the diagram as 
a double square box. 
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Figure 11. Gane and Sarson Data Flow Diagram Symbols. 

Process - represents an activity that transfers or transforms data within the system. 
Processes are labeled with a verb-adjective-noun and numbered hierarchically. They may 
be duplicated on different diagrams and are depicted on the diagram as a box with 
rounded comers. The hierarchical process number is shown in the top portion of the box. 

Data Flow - data that is created, read, updated, or deleted by the system. 
Arrowheads denote the source and destination of each piece of data. Data flows are 
labeled with a noun. They may be duplicated on different diagrams and are depicted on the 
diagram as an arrow. 

Data Store - may represent a computerized file, a database, a manual store, or a 
logical collection of data. Temporary files created by processes within the system are not 
considered in the data flow diagrams. Data stores are labeled with a noun and numbered 
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hierarchically. They may be duplicated on different diagrams and are depicted on the 
diagram as a rectangle. 

3. Process Specifications 

Process specifications are a verbal description of the process. Process 
specifications accompany DFDs and provide a concise summary of each activity. They aid 
the prototype developer in interpreting the data flow diagrams. Examples of process 
specifications include: process name, process number, data inputs, data outputs, 
structured English description of the process logic. 

C. CASE TOOLS 

Information engineering is a flexible methodology supported by many generic 
software CASE tools. Initially, Texas Instruments developed a mainframe based CASE 
tool specifically supporting Martin’s planning, documentation, modeling, analysis, and 
reporting techniques. As information technology evolved from mainframes to networked 
PC architecture, a variety of generic BPR CASE tools supporting central data 
repositories, process modeling, data modeling, structured design, and code generation 
have been developed to support the methodology. EE methodology is comprehensive, 
covering all phases of system the life cycle. The reader will recall that the specific 
techniques used in the IE methodology are not specified and secondary to the integration 
and application of the underlying framework. This flexibility allows EE methodology to be 
tailored to achieve the best possible match of situation to technique. For example, a 
variety of process modeling techniques can be used such as EDEFO, entity-relationships. 
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structure charts, or data flow diagrams. Each modeling methodology is used to show 
different views of the same process. 

Many CASE tools have been designed specifically to support business process 
reengineering, data, and process modeling. Choosing an appropriate CASE tool to assist 
the analyst early in the reengineering effort reduces the length of time to complete the 
project. 

1. Selection Criteria 

CASE tool selection should be done after a reengineering methodology is selected. 
Tool choice should be based on its ability to support all aspects of the reengineering 
methodology. If one tool will not satisfy all of the requirements, the ability for multiple 
tools to share data becomes an overriding consideration. Careful scrutiny of the advertised 
data sharing procedures and interfaces is also advised to enhance seamless integration 
between the tools. Regardless of the reengineering methodology chosen, a CASE tool 
should possess the fodowing capabilities. 

• Capture, visualize, and monitor end-to-end processes 

• Represent process rules and exceptions 

• Dynamically re-plan and reschedule activities 

• Simulate discrete events 

• Analyze the tradeoffs in hypothetical scenarios of process redesign 

• Proactively manage and learn from day-to-day events 
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2. CASE Tool Evaluation 



There are many CASE tools available to support business process reengineering. 
The authors initially considered four such tools: System Architect/BPR Professional, 
BPwin®, Information Engineering Facility™, and TurboBPR. 

Information Engineering Facility™ (EEF™) was developed with James Martin by 
Texas Instruments to support Martin’s information engineering methodology. Although, 
IEF™ offered the most comprehensive support package of the CASE tools, its use was 
rejected outright because both its own operation and the code it generated is based on 
mainframe technology. 

TurboBPR 2.5 is a Windows-based business process reengineering support tool 
developed for the Office of the Secretary of Defense by SRA Corporation. TurboBPR is 
designed specifically to support the DoD functional process improvement methodology. 
TurboBPR consists of five modules to assist with enterprise level information storage, 
strategic planning, activity based cost accounting, and preparation of the functional 
economic analysis. In spite of a formidable reporting feature, TurboBPR 2.5 was not used 
for this research because it lacked integral data and process modeling modules. 

The remaining two competitors. System Architect/BPR Professional (SA/BPR 
Pro), by Popkin Software & Systems Incorporated, and BPwin® (BPwin), by Logic 
Works, Incorporated, are windows based modeling and simulation software designed to 
support a variety of business process reengineering methodologies by documenting 
complex business processes. Both CASE tools offer comparable performance and share 
common features: 
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• A commoi data repository, ensuring model consistency 

• Structured analysis & design techniques for creation of DFDs, STDs and 
structure charts in standard or real-time methodologies 

• Process modeling techniques including EDEFO 

• Object oriented design techniques 

• Forward and reverse engineering capabilities 

• Project documentation facility offering desktop publishing features used to 
create reports and analyze data stored in the central repository 

• Additional features such as common word processor interface, rules checks and 
balancing, import and export capabilities, etc. 

The major difference between SA/BPR Pro and BPwin is that SA/BPR Pro has 
data modeling capability and can generate database schemata in a variety of popular 
databases. BPwin has no data modeling capability of its own. 

Both SA/BPR Pro and BPwin have excellent on-line tutorial support. BPwin’s 
tutorial was particularly relevant to this research because IDEFO modeling examples are 
used to illustrate the tool’s features. An inherent disadvantage of SA/BPR Pro’s additional 
features is the required diversity of the on-line tutorial. Despite comprehensive coverage, 
the tutorial is more complex and leaves the user with a sense that BPwin is more intuitive 
and easier to operate. To fully exploit all of SA/BPR Pro’s many features, considerably 
more time must be devoted to learning to operate the tool. 

SA/BPR Pro has a more versatile graphics package for developing data flow 
diagrams. BPwin’s structured analysis and design screen graphics package limits the user 
to a single 8.5 by 1 1 inch page, often resulting in cluttered diagrams. SA/BPR Pro allows 
diagramming on multiple pages. 
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An attractive characteristic of both SA/BPR Pro and BPwin is the advertised data 



sharing capability with the competition. In theory, this feature would permit parallel 
development of the data and process models using the premier CASE tool for each and 
allow maintenance of a virtual metadata encyclopedia. The choice of closely integrated 
tools that allow data models and process models to share data sounds appealing and was 
attempted. However, as parallel model development progressed, the authors discovered 
that in order to “share” data between models required exporting the data into Microsoft 
Word, converting the file into a comma delimited format, and finally importing it into the 
other model. As the number of activities, arrows, relationships, entities, and attributes 
continued to grow, this import/export routine became quite cumbersome. Unfortunately, 
this procedure was necessary even for minor changes to maintain model consistency. 
SA/BPR Pro’s single data repository would have eliminated this inconvenience. 

A feature BPwin has that SA/BPR Pro does not have is an advertised compatibility 
with a sibling data modeling product, ERwin. ERwin was the CASE tool chosen for data 
model development. Their common manufacturer claimed seamless data sharing between 
the two products by building identical data structures within the encyclopedia of each tool. 
However, as parallel model development progressed, it was discovered that a similar 
import/export routine was necessary to transfer data model information from ERwin into 
BPwin. This process .hd not require the exported file to be comma delimited before 
import, but the two data encyclopedia structures were not identical. Initially, definitions 
generated and stored by ERwin could not be imported into BPwin. In spite of this fault 
process model development was not impeded because data element and data table names 
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were imported and could be used. Deficiencies in the BPwin data dictionary were 
overcome by a software patch distributed by the vendor which enabled the data dictionary 
file of both tools to produce one encyclopedia containing all model information. 

3. CASE Too! Selection 

CASE tool selection for the MCI modernization project is based on supportability 
of the information engineering methodology and the IDEFO modeling technique. In spite 
of the fact that Texas Instruments’ Integrated Engineering Facility™ CASE tool was 
developed specifically to support the IE methodology, its mainframe theme made it 
unsuitable for MCI modernization use. TurboBPR2.5, too, was unsuitable because it did 
not support process modeling with an integrated module. CASE tool contenders were 
quickly narrowed to System Architect/BPR Professional and BPwin®. BPwin® was 
selected over to System Architect/BPR Professional for several reasons. 

• Advertised interoperability with its sibling data modeling product, ERwin®. 
ERwin® / as the CASE tool selected for the data modeling portion of the MCI 
modernization project. 

• Intuitive functionality made BPwin® easier to learn than System 
Architect/BPR Professional. 

• Economically, the BPwin®/ERwin® combination was more affordable than 
System Architect/BPR Professional. 



96 



VI. MCI ENTERPRISE ANALYSIS 



This chapter describes the process modeling effort in support of the MCI 
modernization project. The chapter begins with a detailed description of the enterprise 
analysis. It includes a survey of the data collected with an explanation of its analysis. The 
chapter concludes wim the presentation of the enterprise business model. 

A. ENTERPRISE ANALYSIS OVERVIEW 

An enterprise analysis provides a high-level overview of the information 
requirements of an organization. The objective of this effort defines an architectural 
framework for future development. The framework consists of three major components: 
information, business system and technical architecture. The three architectures lay the 
foundation from which the organization can build an information system to manage its 
information resources and support its business activity. (Martin, 1990B) 

A high-level perspective provides a basis from which detailed analysis in 
subsequent stages can be pursued. It serves as a mechanism to identify interdependency 
and redundancy of business activities within the organization. The first stage of Martin’s 
IE methodology provides a technique to identify, evaluate, plan and manage the use of 
information to meet the organization’s information system requirements. 

B. MCI ENTERPRISE ANALYSIS 

The enterprise analysis conducted for MCI was accomplished in two parts. The 
first part identified the organizational units, locations, functions and data subjects for MCI. 
This was a data collection effort directed at defining the architectural framework of 
development of MCI’s information system. The second part focused on analyzing the data 
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collected to document an enterprise overview of MCI. The documentation analyzes the 
relationships between organizational units, locations, functions and data subjects, as 
illustrated in Figure 12, using charts and matrices. 




Figure 12. Enterprise Analysis Components. 



After Martin, 1990B. 

C. IDENTIFY INFORMATION SYSTEM REQUIREMENTS 

The NPS team traveled to the Marine Corps Institute in Washington, DC for the 
MCI Redesign kick-off meeting held August 26-29, 1996. Prior to the meeting, the NPS 
team received a read-ahead package from MCI. The package included a description of the 
existing organizational structure, an incomplete business model previously prepared by an 
independent contractor, an existing data dictionary, a task breakdown of Student Services 
Department, historical briefing packages and background documentation on Marine Corps 
Institute. Each department head presented a brief that identified the department’s 
organization, key personnel, mission and functions. The meeting provided a means to 
observe the business culture and political environment of MCI. Additional documentation. 
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such as training manuals, SOPs, existing input screen shots, and management reports, was 
obtained during interviews and in response to requests following the initial meeting. 

MCIAIS is a mission-critical system to MCI. The Student Services Department is 
the chief beneficiary of the information stored within MCIAIS. This is primarily due to the 
lost functionality of various sub-systems over time. It was apparent that each department 
head was frustrated because the current MCIAIS was driving the way they did business, 
instead of enabling improvements to process efficiency. 

1. Organization Structure 

Chapter II described the organizational structure into which MCI fits. The 
enterprise analysis focuses on MCI’s reporting structure. An understanding of the MCI in 
this context was important to identify stakeholders to interview and provided a basis for 
determining responsibilities for the activities of the enterprise (Martin, 1990B). 

The Director of Marine Corps Institute is also the Commanding Officer of Marine 
Barracks, Washington, DC. This billet is staffed by a Marine Corps Colonel. The position 
as Commanding Officer carries the responsibility for the activities of the Marine Barracks 
companies, one of which is the MCI Company. (MCI In-Brief, 1996) 

The Deputy Director is accountable to the Director of MCI. This billet is staffed by 
a Marine Corps Lieutenant Colonel. This position is responsible for the performance of 
MCI Company in executing the seven MCI mission tasks identified in Chapter II. (MCI 
In-Brief, 1996) 

MCI Company is composed of six departments: Headquarters Department, 
Professional Military Education Department, Occupational Skills Department, Logistics 
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Department, Student Services Department and Management Information Systems 
Department. The authors also considered Marine Corps unit’s Training Departments to be 
a department because of its functions in the administration of student records. (MCI In- 
Brief, 1996) 

The Headquarters Department is composed of four sections: Administration 
Section, Operations and Training Section, Edit Division and Performance Improvement 
Requirements (PER)Scction. Headquarters Department exercises staff cognizance over the 
MCI's departments for the production and support of distance education and training 
materials. (MCI In-Brief, 1996) 

The Professional Military Education Department (PMED) consists of six divisions: 
Command and Staff College Nonresident Program Division, Amphibious Warfare School 
Nonresident Program Division, Warfighting Skills Nonresident Program Division, 
Sergeants Nonresident Program, Staff Non-Commissioned Officer (SNCO) Career 
Nonresident Program and Staff Non-Commissioned Officer (SNCO) Advanced 
Nonresident Program Division. PMED provides distance education that is a prerequisite 
for, or parallels. Mar ;se Corps resident school curricula. (MCI In-Brief, 1996) 

The Occupational Skills Department (OSD) is comprised of seven divisions: 
Command and Control Division, Combat Operations Division, Combat Support Division, 
Combat Service Support (CSS) Operations Division, Administration/Finance Division, Job 
Aids Division, and Graphics/Layout Division. OSD develops and maintains nonresident 
courseware and military occupational specialty (MOS) specific job aids, to include the 
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Marine Battle Skills Training and the Battle Drill Guide for use by the active and reserve 
components of the Marine Corps.(MCI In-Brief, 1996) 

The Logistics Department is comprised of six divisions: Stock Control Division, 
Demands/Fiscal Division, Property Control/Support Division, Warehousing Division, 
Postal Division, and Reproduction Division. Logistics Department procures, stocks, 
packages, and distributes courses and training products, produces and manages the fiscal 
plan, provides postal services, organizational supply, logistical support, printing and 
reproduction services to MCI and Marine Barracks. (MCI In-Brief, 1996) 

The Student Services Department (SSD) is comprised of five sections: Immediate 
Assist Section, Enrollment Section, Grading Section, Unit Activity Report (UAR) Section, 
and Registrar Section. SSD is responsible for the enrollment, grading, and management of 
student records for MCI’s distance education and training programs. (MCI In-Brief, 1996) 
The Management Information Systems Department (MISD) is comprised of two 
sections: Information System Management (ISM) Section and Programming Section. 
MISD provides information systems support to the Marine Barracks and to MCI in the 
enrollment, grading, and management of student records. (MCI In-Brief, 1996) 

The Marine Corps unit Training Department is normally one person, the unit 
Training NCO. The Training NCO is a MCI representative within the Marine Corps unit, 
in much the same way as Lieutenant Colonel Harllee set up when correspondence courses 
were first offered 77 years ago. 
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2. Business Locations 



The physical location of each organizational unit is important to the development 
of technical architecture. It provides a basis for determining the physical attributes the 
information system must satisfy for the business activities of the enterprise. (Martin, 
1990B) 

A tour of MCI during the initial brief revealed the location of the MCI offices and 
work spaces where the various business activities take place. The office for Director of 
MCI is located at the Marine Barracks, 8 111 and I streets. This is approximately six blocks 
from the MCI buildings. The office for the Deputy Director is located on the second floor 
in building 220, Lejeune Hall, at the Washington Navy Yard. MCI Headquarters 
Administrative and PIR sections, PMED, SSD and MISD are also located on the second 
floor of Lejeune Hall. OSD, Operations and Training section, and the Edit Division are 
located on the first floor of Lejeune Hall. The Logistics Department is located, across the 
street from the rest of MCI, in building 169 of the Washington Navy Yard. The Marine 
Corps unit’s Training Department is located in literally hundreds of operating locations 
around the world. 

3. Business Functions 

The enterprise business functions were decomposed from seven high-level 
functional areas. Functional areas refer to the major business activities and serve as the 
starting point for further decomposition in the subsequent Business Area Analysis. The 
functional decomposition of MCI’s enterprise activities is illustrated in Figure 13. 

• Headquarters Support - The functions that provide planning, parade support 
and personnel administration for MCI. 
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• Course Development - The functions that support the design, writing, revising, 
staffing, and production of MCI courses, programs, and job aids. 

• Course Management - The functions that support the advertising, budgeting, 
training and analysis of MCI courses, programs, and job aids. 

• Student Services - The functions that support data entry for student record 
management, student servicing, grading, and course completion certification. 

• Information System Management - The functions that support the network 
management, programming and database administration for MCI. 

• Warehouse and Distribution - The functions that support purchase, receipt, 
storage, inventory, packaging, distribution and disposal of MCI courses, 
programs, and job aids. 

• Unit Interaction - The functions performed by the Marine Corps unit training 
departments in support of the administration of MCI courses, programs, and 
job aids. 




Figure 1?. MCI Enterprise Level Functional Area Decomposition. 
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A business function is a collection of related activities which completely support 
one aspect of furthering the enterprise’s mission (Martin, 1990B). Figure 14 provides an 
overview of many functions performed by the various organizational units in the 
development, distribution and management of the distance training and education courses 
and programs. The functions represented in the flowchart were used to generate an initial 
candidate list of business functions performed by the MCI enterprise. The business 



function candidate list was revised several times as each organizational unit was analyzed. 



MC Doctrine 




SSD.M1SD 



MISD, SSD, Logistics 



Figure 14. Product Development, Distribution, and Management Flowchart. 



Business functions were then defined. Defining the business functions is important 



to understanding the business process as a whole. However, at the enterprise level, 



business function definitions are independent of the organizational structure (Martin, 
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1990B). The definitions were not linked direcdy to an MCI organizational unit or its 
location because the reporting structure may change but the functions still must be 
performed. A total of 33 candidate business functions were identified and defined during 
the enterprise analysis. 

• Advertising - To publish or announce the availability of Programs, Courses 
and Job Aids in the MCI Course Catalog, military newspapers, ALMARs, 
MARINE magazine, etc. 

• Analysis Of Effectiveness - To collect data from returned exams and student 
feedback sheets, and analyze data in order to revise exam questions or 
Program and Course text. 

• Budgeting - To manage budget categories for developing, producing and 
distributing MCI Programs, Courses and Job Aids. 

• Course Design - To identify and establish the design specifications, schedule 
and prerequisites for MOS Courses and Job Aids to meet Marine Corps 
training and education requirements for target audience. 

• Course Revising - To revise Job Aids and MOS Course text, examinations and 
related material based on feedback from students. Course sponsors, CG, 
MCCDC a id internal analysis of effectiveness. 

• Course Staffing - To allow newly designed MOS Courses and Job Aids to be 
reviewed by all of the agencies and departments responsible for its production 
and distribution. 

• Course Writing - To research and write the MOS Course text, components, 
examinations and Job Aids. 

• Customer Servicing - To respond to customer inquiries of any nature (as it 
relates to the MCIAIS) and process customer requests for MCI action 
(enrollment, material request, update information, etc.). This service supports 
inquiries received by telephone, electronic mail, U.S. Mail, or over the counter. 

• Database Administration - To download and upload TFS and unit diary 
information into the MCIAIS; to upload and service the automated telephone 
Conversant system database. To commit daily transaction files; to troubleshoot 
database or related problems; to backup database. 
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• Delivering - To deliver Program materials. Course materials. Job Aids, 
Diplomas, Course Completions certification and course components to 
students. 

• Disposing - To purge obsolete Program and Course materials. Job Aids and 
course components. 

• Editing - To review new and revised Programs, Courses and Job Aids for 
Instructional System content and quality. 

• Exam Proctoring - Monitoring examinations to Marines in the fleet to ensure 
compliance with the MCI Procedures Manual. 

• Grading - To record the scores of examinations, in the MCI student database, 
graded by both automated & manually means. 

• Inventory - To manage on-hand quantities and locations of on-hand material. 

• Layout & Graphics - To create new graphics, improve existing graphics, and 
maintain library of appropriate graphics and artwork for Program text, Course 
text, and Job Aids. 

• Manage Networks - To install, manage and maintain telephone and data 
network equipment. 

• Ordering - To requisition Program and Course materials, Job Aids and course 
components distributed by MCI. 

• Packaging - To assemble and shrink wrap Program and Course materials, Job 
Aids and course components for distribution and storage. 

• Parade Support - To coordinate MCI personnel to support the ceremonial 
activities at the Marine Barracks. 

• Planning - To schedule and coordinate all planning associated with MCI 
Parades and Ceremonial Details involving MCI personnel. 

• Program Design - To identify and establish the design specifications, schedule 
and prerequisites for PME courses to meet Marine Corps training and 
education requirements for target audience. 

• Program Revising - To revise PME Program text, examination and related 
material subject to feedback from students. Program sponsors, CG, MCCDC, 
and internal analysis of effectiveness. 
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• Program Staffing - To allow a newly designed or revised PME Program 
content to be reviewed by all of the agencies and departments responsible for 
its production and distribution. 

• Program Writing - To research and write the PME Program text, components 
and examinations. 

• Programming - To write program source code that corrects or enhances 
database administration. 

• Receiving - To receipt for materials that will be stored in the warehouse. 

• Registrar Servicing - To research and produce diplomas, completion 
certificates and transcripts for students. 

• Reproduction Servicing - To prepare negatives, camera-ready originals, and 
print specifications for contract orders to commercial printers, maintain 
negatives and camera-ready copy for MCI courses; to reproduce/print original 
documents for MCI or Marine Barracks in quantities less than 25,000. 

• Storing - To stock received materials. 

• Student Activity Transactions - To manage student records and monitor the 
transaction processing system. 

• Training - To coordinate training of MCI course writers and programmers. 

• Unit Reconciling - To provide MCI with feedback from units so MCLAIS can 
be validated and updated if required. 

4. Data Subjects 

Data subjects refer to a higher level grouping of data entities. A candidate list of 
data subjects, provided in Table 4, was developed by the NPS team data modeler. The 
candidate list of data subjects, their definitions, attributes and relationships are detailed in 
the Analysis, Design, and Prototype Implementation of a Contemporary Information 
System for the Marine Corps Institute, Preliminary Report, (Kamel et al., 1997). The data 
subjects were decomposed in the subsequent Business Area Analysis. 
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Advertisement Information 


Job Aid Information 


Component Information 


Job Aid Copy Material Information 


Copy Material Information 


MCI Personnel Information 


Course Information 


MCTFS Personnel Information 


Course Copy Material Information 


Order Information 


Course Developers Information 


Program Information 


Customer Information 


Program Copy Material Information 


Events Information 


Program Developers Information 


Exam Information 


Purchase Information 


Financial Information 


SSD Personnel Information 


Inventory Information 


Student Information 


IS Equipment Inventory Information 


Training Information 


Issue Complaint Information 


Warehouse Information 



Table 4. Candidate List of Data Subjects. 



D. DOCUMENT THE ENTERPRISE 

The second part of the ISP stage documents the information requirements, 
identified during the first part. Graphic representations helped to summarize the collected 
data. The enterprise analysis of MCI was documented with an organization chart and 
several planning matrices which illustrate the relationships of MCI’s organizational units, 
locations, business functions and data subjects. 

1. Document Current MCI Organization 

The reporting structure of MCI Company was documented using an organizational 
chart. The organization chart. Figure 15, illustrates the hierarchical structure common 
among traditional military organizations. The sections are logically arranged to report to 
the respective departments. The dashed lines represent indirect operational support. In one 
case, the MCI Company provides parade and logistical services to the Marine Barracks 
operations. In the other case, Marine Corps units provide enrollment processing and 
reconciliation services necessary for MCI distance training operations. 
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Figure 15. MCI Company Organization Chart. 

2. Document Current Locations, Functions, and Data Subjects 

The relationships between the organizational units, locations, functions and data 
subjects define the architectural framework of the enterprise. A common technique used to 
document and analyze such relationships is to develop a series of planning matrices that 
cross reference and validate the various elements of the organization. Eight matrices were 
used to define the information and business system architecture for the MCI enterprise 
analysis: Organizational Unit versus Location, Function versus Organizational Unit, 
Function versus Location, Data Subject versus Organizational Unit, Data Subject versus 
Location, Data Subject versus Function (CRUD Matrix), Function versus Data Subject 
(CR Matrix) and Function versus Data Subject (Clustered CR Matrix). 

The Organizational Unit versus Location matrix, provided as Figure 16, 
summarizes the MCI organizational units and the locations where their business activity 
takes place. The matrix validated the organizational units with their locations. This 
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Figure 16. Organizational Unit versus Location Matrix. 



validation ensured all organizational units were accounted for in the analysis. Their 
locations would be considered in the technical architecture development. The “@”marks in 
the same columns depict organizational units which operate from the same location. The 
marks in the same rows indicate organizational units which operate in different locations. 

The Function versus Organizational Unit Matrix, provided as Figure 17, 
summarizes the functions performed by each MCI organizational unit The Function 
versus Location, provided as Figure 18, summarizes the locations in which the functions 
are performed. These iwo matrices validated the functional decomposition by ensuring 
that every function was mapped to an organizational unit and that every organizational 
unit was involved in an identified function. The matrices also show the extent to which 
departments share data and perform redundant functions. 
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Figure 17. Function versus Organizational Unit Matrix. 



Two other matrices were produced by the NPS data modeler to illustrate the 
relationship between the data subjects with the organizational units and the locations. 
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Figure 18. Function versus Location Matrix. 



Together, these five matrices served to cross reference and validate the candidate data 



subjects and business functions and improved the project team’s understanding of MCFs 



current strategy for conducting business. 

The relationship between business functions and the data subjects revealed the 
Information Architecture. Three matrices were used to group business functions and data 
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subjects into natural business systems and natural data stores. These groupings identify the 
division of business areas in preparation for further detailed analysis. 

Each function was evaluated to determine if it would create , read , update , delete , 
or archive the corresponding data subject. A “C”, “R”, “U”, “D” and/or “A” was placed in 
the row-column representing that data subject and function analyzed. Collating each 
combination produced the Data Subject versus Function CRUD Matrix given as Figure 
19. 

A CR Matrix, provided as Figure 20, was used as an intermediate step to generate 
the groupings necessary to identify the business areas. A “C” was substituted for every 
“C”, “U’\ “D” or “A”. The columns and rows of the CR Matrix were arranged to create 
clusters of related functions that create, update, delete and archive associated data 
subjects. The resulting Clustered CR Matrix revealed natural groupings that verify the 
natural division of sub-systems in preparation for the Business System Design stage. 

3. MCI’s Current Business Model 

The Clustered CR Matrix, provided as Figure 21, revealed eight business sub- 
systems that directly influence the MCI information requirements: Personnel 
Administration, Ceremonial, Program and Course Development, Program and Course 
Management, Student Service Support, Information System Management, Warehouse and 
Distribution, and Unit Interaction. 

The Clustered CR Matrix revealed two details worthy of discussion. First, the 
Personnel Administration and Ceremonial sub-systems influence business activity of MCI 
but actually have no direct interface with MCIAIS. Second, the Unit interaction sub- 
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Figure 19. Data Subject versus Function (CRUD) Matrix. 
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Figure 19. Data Subject versus Function (CRUD) Matrix continued. 
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Figure 20. CR Matrix. 
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Figure 21. Clustered CR Matrix. 
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system uses data produced by MCIAIS and generates data input through MISD, but does 
not actually create or read a data subject directly. These three sub-systems were left in the 
matrix to give a complete representation of the business system architecture to consider 
during the reengineering phase. 

The MCI Preliminary Business Model, Figure 22, represents the division of the 
enterprise into lowet evel business areas and functions. Subsequent analysis of each 
business area can be performed independently based on priorities determined during this 
initial evaluation to s isfy the organizational requirements. MCI management determined 
the business activities of Student Service Support should receive the highest priority based 
on the information requirements and its role in the MCIAIS-I3 implementation plan. 

The boundaries of the business area analysis for Student Service Support adds 
definition to the MCI Modernization Project scope. The analysis did not focus on how the 




Figure 22. MCI Preliminary Business Model. 
118 



database was populated, but on the data with which it would be populated, the SSD 
processes that use the data, and the interaction between the two. The key business areas, 
functions, and data subjects, identified during the MCI enterprise analysis, are illustrated 
with Figure 23. The business areas are represented by large rounded boxes. The functions 
are represented are contained within the respective business area. External entities are 
represented with rectangles. The arrows represent interaction. The dashed line represents 
the boundary, and focus of the BAA. Migration of the legacy system’s functionality 
required identification of the data entities encountered with each interaction. The As-Is 
process model was developed to identify those details. 
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VII. MCI BUSINESS AREA ANALYSIS 



This chapter further describes the process modeling effort in support of the MCI 
modernization projec . The chapter begins with a detailed description of the Business Area 
Analysis and the subsequent development of the As Is Model for the Student Services 
Support business area The detailed description of the tailored application of Business 
Process Reengineering follows. The chapter concludes with the presentation of To Be 
Process and Information System Models for the Student Services Department. 

A. BUSINESS AREA ANALYSIS OVERVIEW 

The Business Area Analysis (BAA) is the second stage of Information 
Engineering. The BAA is a refinement to a specific subset of the enterprise analysis. There 
are six objectives of a BAA project (IEF Guide, 1990): 

1. To fully identify and define the type of data required 

2. To identify and define the business activities that make up each business 
function 

3. To define the data required for each business activity 

4. To identify the necessary sequence of business activities 

5. To define how business activities affect the data 

6. To produce a plan for Business System Design (BSD) within a prioritized 
sequence of business systems. Normally, several business systems will be 
defined to support a single business area. 

The ultimate goal is to refine the business areas identified during the enterprise 
analysis. The ISP stage targeted the Student Service Support as the first business area for 
detailed analysis. Boundaries were established to identify the resources required to support 
development of a nev information system that will, at least, maintain the same 
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functionality provided by the current MCIAIS in a new relational database. The detailed 
analysis focused on definition and refinement of the business activities performed by SSD, 
the objects that generate the activity, and the interaction between them. 

B. MCI BUSINESS AREA ANALYSIS 

The BAA for Student Service Support is built upon the information gathered 

during the ISP stage. Having already identified the functional areas and the business area 
to analyze, the NPS team initiated development of the As-Is Process Model. A detailed 
functional decomposition of the Student Service Support business area was done. The As- 
Is process model was presented as node tree and process decomposition diagrams and 
circulated for review. Business Process Reengineering techniques were applied. A To-Be 
process model was developed using IDEFO modeling technique. The proposed To-Be 
Process Model was circulated again for review. The refined model was validated using 
matrices and clustering as performed during the ISP stage. Once validated, an information 
system model was de eloped using data flow diagrams. The products of this analysis 
provided the necessary information to develop a system architecture plan, a To-Be Data 
model, a To-Be Proc xs model, an information system model, and a prototype that 
validated the methodology. 

1. SSD BAA Implementation 

The As-Is process model represents the business activity of the Student Services 
Department in August 1996. Model development began with functional decomposition. 
The student service support business area was decomposed eight levels into 499 activities. 
A process decomposition diagram and node tree diagrams were developed to document 
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the analysis. This technique provided sufficient detail to obtain a thorough understanding 
of SSD business. 

The process decomposition and node tree diagrams were developed with the 
BPWin® CASE tool. BPWin® was useful for the development of the metadata 
encyclopedia. It proved to be very simple to use and, after receiving a software patch, 
integrated well with its sibling data modeling CASE tool, ERWin®. 

A complete IDEFO model was not produced for the As-Is processes. The authors 
felt that too much time would be spent developing naming conventions for activities, 
relationships and entities of the non-relational database, which would detract from the 
reengineering effort However, the activities that were likely to apply in the To-Be process 
model were defined and then refined when applied. 

During the reengineering phase it became apparent that an As-Is process should 
also include selected processes from other functional areas. Sufficient information had 
been obtained during the ISP stage to create high-level As-Is process models for other 
business areas: Course and Program Management, Course and Program Development, 
Warehouse and Distribution, and Information System Management. 

These decomposition diagrams were useful in the data model development. The 
enterprise level CRUD matrix revealed a significant amount of data retrieved by SSD but 
owned by other business areas. Course or program information, stock status, MCTFS 
information are just a few examples. The data model needed to reflect those data subjects 
for MCIAIS-n to retain the same functionality. 
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2. As-Is Model Details 



All of the activities depicted in the SSD process model are prefixed with “SSD” to 
distinguish it from models developed for other areas. Since the SSD As-Is process model 
is too large to print as a single document, it was broken into modules for readability. Only 
selected material will be presented to illustrate specific points. The model is provided in its 
entirety as Appendix B. 

The number of activities clearly demonstrates the level of detail pursued in the 
BAA of Student Services. This detail provided the NPS team with a thorough 
understanding of SSD activity. Additional model details must be gleaned from careful 
study of the process decomposition diagram or the node tree diagrams included as exhibits 
to Appendix B of the Analysis, Design, and Prototype Implementation of a Contemporary 
Information System for the Marine Corps Institute, Final Report, (Kamel et al.,1997). 

a. Functional Decomposition 

The b isiness area of Provide Student Support was decomposed eight levels 
down to the primitive processes - a total of 499 activities. The first level identified six 
functions: OBTAIN CUSTOMER INPUT, MAKE CHANGES TO STUDENT’S 
COURSE ACTIVITY RECORD, GRADE STUDENTS EXAMINATIONS, PROCESS 
UNIT ACTIVITY REPORTS, PROCESS REQUESTS FOR MATERIAL, and 
PROCESS REQUEST FOR REGISTRAR ACTION. Figure B-l, Appendix B is a node 
tree diagram of the top three levels. 

The OBTAIN CUSTOMER INPUT- SSD1 function was decomposed into 
four processes: PROCESS INCOMING PHONE CALLS, SORT INCOMING U.S. MAIL, 
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SORT INCOMING ELECTRONIC MAIL, and PROCESS WALK-IN CUSTOMERS. This 



function represents the front end of customer service by receiving and replying to 
customer requests. One other method of customer processing is through the Marine Corps 
Unit Diary System. This method however is a process performed within the Information 
System Management business area and requires no student services interface. 

The MAKE CHANGES TO STUDENT’S COURSE ACTIVITY 
RECORD - SSD2 function was decomposed into four processes: PROCESS REQUEST 
FOR ENROLLMENT, PROCESS CHANGE TO STUDENT INFORMATION, PROCESS 
REQUEST FOR ADMINISTRATIVE ACTION, and PROCESS STANDARD REQUEST 
FOR MATERIAL. This function represents most of the user interface with MCLAIS. This 
activity is replicated as sub-processes below OBTAIN CUSTOMER INPUT. In 
developing the As-Is model, the authors intended to use the replicated processes to model 
the different modes of access to MCI as a target for reengineering. 

The GRADE STUDENTS EXAMS - SSD3 function was decomposed into 
four processes: PROCESS PRE-SLUGGED DP-37s, PROCESS GENERIC DP-37 s, 
PROCESS OPSCAN ERROR USTING REPORT, and PROCESS HAND GRADED 
EXAMS. This function represents processing student lessons and examinations and 
products resulting form the activity. 

The PROCESS UNIT ACTIVITY REPORTS - SSD4 function was 
decomposed into two processes: WORK RETURNED UARs and PROCESS OUTGOING 
UARs BY US MAIL. This function represents the reconciliation processes between MCI 
and the Marine Corps unit Training NCO. 
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The PROCESS REQUEST FOR MATERIAL - SSD5 function was 
decomposed into four processes: SEGREGATE REQUEST FOR REGISTRAR ACTION, 
SEGREGATE STANDARD REQUESTS FOR MATERIAL, PROCESS “ REQUEST FOR 
MATERIAL ” FORMS, and SEGREGATE “OFF-LINE REQUEST' FORMS. This 
function represents the processes to satisfy customer requests for new or replacement 
materials. Many of these activities are replicated as lower level sub-processes in SSD1. 

The PROCESS REQUESTS FOR REGISTRAR ACTION - SSD6 
function was decomposed into two processes: ISSUE (REISSUE) DIPLOMA and 
PROCESS TRANSCRIPT REQUEST. This function represents the activities of issuing 
diplomas and transcripts. 

b. Detailed Analysis 

The detailed analysis was done by reviewing each provided SSD task 
breakdown sheet and modeling the activities described. Additional details were obtained 
from the MISD’s Standard Operating Procedures manual, the Marine Corps Institute 
Procedures Manual, telephone interviews, and replies to our specific requests. 

Model development revealed a significant number of manual activities. This 
drew a lot of attention because the manual processes seemed to cause a bottleneck to 
production flow. Modeling manual activities effectively during the As-Is effort simplified 
the subsequent reengineering effort. 

OBTAIN CUSTOMER INPUT, activity number SSD1, models the 
process of receiving customer input. Figure B-2, Appendix B is a node tree diagram which 
illustrates four levels of that function’s decomposition. The figure depicts the flexibility 
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MCI applies to servicing customers by receiving their input in various forms: telephone, 
walk-in, electronic mail, and U.S. Mail. The model also demonstrates a relatively standard 
method of handling the input. Telephone and walk-in customers receive immediate 
attention while all other input is sorted and segregated for assembly line processing. 

U.S. mail processed by the Student Services Department is opened and the 
contents manually segregated for subsequent distribution. MCI administrative procedures 
specify that enrollment requests are submitted with an MCI Enrollment Application Card 
(R-l Card). Other requests are submitted with a Student Request/Inquiry Form (R-l 1 
Card). Lessons and examinations are submitted on two different sized forms of an optical 
character recognition (OCR) capable form (DP-37). One form was pre-formatted with 
student and course information and distributed with the course materials when enrolled. 
The other is a generic form which the student completes when the examination is returned 
for evaluation. Course materials are distributed with a feedback form which is submitted 
when a lesson or exam is completed. Many of the Non-Resident Program examinations are 
essay type and not OCR capable. All requests for transcripts must also be written. 
Consequently, there is a single point of entry to process customer input by U.S. Mail. 

Electronic mail addressed to MCI is received in one electronic, 
organization mailbox (OMB), unless addressed to an individual. Electronic mail 
processing has not been standardized except for electronic Unit Activity Reports. 
Regardless of the subject matter, all electronic mail received in the OMB is printed, 
segregated and distributed for subsequent processing. The content of electronic messages 
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cover the same variet y of input as U.S. mail minus lesson and course examinations, 
without the convenience of a standard format. 

A student or Marine Corps unit representative, i.e.. Training NCO, First 
Sergeant, section non-commissioned officer in charge, can obtain course status through an 
MCI automated voice recognition system (AVRS) called Conversant. The caller contacts 
MCI’s toll free number, inputs the student’s social security number and course number, 
and Conversant returns the student’ course status. Conversant accesses a copy of the MCI 
student database resident on a remote server. 

MAKE CHANGES TO STUDENT’S COURSE ACTIVITY RECORD, 
activity number SSD'!, models the processing transactions that effect a student’s record 
within MCIAIS. Figure B-3, Appendix B is a node tree diagram which illustrates four 
levels of that function’s decomposition. Once an enrollment, inquiry, or other request is 
received, segregated and distributed, processing is the same as would be administered for 
a telephone or walk-in customer. The same screens are used to access data from MCIAIS 
in the same sequence regardless of customer entry mode. Transaction codes are entered by 
the user to reflect input that changed student activity records. A list of transaction codes 
are maintained near each user terminal. One interface characteristic identified user-entered 
data is not carried forward when transitioning between screens. This required multiple 
entries of the same information and increased the likelihood of user error. 

GRADE STUDENTS EXAMS, activity number SSD3, models the 
processing of lesson^ and examinations received from students and the output generated. 
Figure B-4, Appendix B is a node tree diagram which illustrates four levels of that 
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function’s decomposition. Two types of DP- 37s are processed: pre-slugged DP-37s 
which are formatted prior to distribution course material issue, and generic DP-37s which 
are not. The DP-37 s contain the same information but are different sizes. They must be 
segregated prior to processing. The DP-37 s are scanned by an OCR reader, Scantron, and 
the data is collected in a file on a disk. The DP-37s successfully read are placed in a 
pending file. Those not read must be hand graded. DP-37s failed scanning because of form 
damage or key fields weren’t completed. The disk is delivered to MISD for batch 
processing during the nightly cycle. 

The OPSCAN Error Report, a list of all lessons and exams not processed 
by MCLAIS, is produced after the cycle is run. The DP-37s on that list must be pulled 
from the pending file and manually processed according to the error code. The remaining 
scanned DP-37 s are moved to a completed file. The generic DP-37 increased the 
likelihood of incomplete forms, forms completed incorrectly, and forms received from 
individuals who hadn’t been enrolled. The generic form was created to simplify course 
material packaging and reduce distribution delays. 

Hand graded examination and PME examination scores are entered into 
MCLAIS manually. Corrected DP-37s from the OPSCAN Error Report are either 
processed through the Scantron again or entered into MCIAIS manually. 

PROCESS UNIT ACTIVITY REPORTS, activity number SSD4, models 
the process of reconciling MCIAIS student record activity with the records maintained by 
the Marine Corps unit. Figure B-5, Appendix B is a node tree diagram which illustrates 
four levels of that function’s decomposition. Unit Activity Reports (UARs) are generated 
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during a mid-month and monthly cycle batch process by MISD. UARs are produced in 
electronic form only during the mid-month cycle and both electronic and paper form at the 
end of the month. The unit must request, reconcile and return electronic UARs following 
procedures set forth in the Marine Corps Institute Procedures Manual. Procedures for unit 
reconciling UARs are the same regardless of the method of distribution. The unit reports 
the differences with annotations to the UAR and returns it to MCI. MCI processes the 
changes following the same procedures. Each annotation associated with a student record 
requires that record to be viewed on a terminal screen and checked to see if that record 
reflects the remark. If not, the change is entered following the same procedures as 
described during activity SSD2 - MAKE CHANGES TO STUDENT’S COURSE 
ACTIVITY RECORD. There is no action required by Student Services to process 
outgoing electronic UARs. The UARs that are produced in paper form must be packaged, 
addressed and mailed to units not on electronic distribution. 

PROCESS REQUEST FOR MATERIAL, activity number SSD5, models 
the process of responding to customer and student requests for material. Figure B-6, 
Appendix B is a node tree diagram which illustrates four levels of that function’s 
decomposition. Material requests fall into four general categories: standard material 
request, request for material, off-line request for material, and transcripts. Each category 
entails a greater degree of manual activity. A standard material request has a transaction 
code that can be entered at the terminal and MCLAIS will generate a mailing label for 
logistics to complete the distribution process. Material in this category includes: a 
duplicate issue of job aids, course or program material, issuing course or program material 
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without an enro Ilmen;, and a duplicate issue of a completion certificate or diploma. A 
request for material is for material required to support the Marine Corps unit Training 
NCO performing MCI liaison functions. Material in this category includes: pre- addressed 
postage paid envelopes, blank DP-37s, course catalog. Marine Corps Institute Procedures 
Manuals, R- 1 Cards and R- 1 1 Cards. Activities for this type of request include filling out a 
form, packaging the material from stock maintained in the Student Services, addressing 
the package and forwarding the package to Logistics for mailing. Off-line request material 
is for an individual component of a course, program or job aid or course material for a 
foreign military officer. This requires completion of a different form, approval by 
operations officer, preparation of an address label, and delivery to Logistics for mailing. A 
transcript request must be in writing. It is delivered to the registrar for processing in 
accordance with activity SSD6.2. 

PROCESS REQUEST FOR REGISTRAR ACTION, activity number 
SSD6, models the production of transcripts and diplomas. Figure B-7, Appendix B is a 
node tree diagram which illustrates four levels of that function’s decomposition. One of 
the MISD grading program batch processes produced a diploma print file. The file is 
transferred to a disk and delivered to the Registrar. The Registrar produced the diplomas, 
duplicate diplomas and envelopes from the file by running a program on a local PC 
connected to a LaserJet printer. Transcripts must be individually researched using active 
and archived MCIAIS student records and microfiche records. The collected data is put 
onto a form, typed on a computer terminal, printed and mailed. 
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Task vvorksheets provided to the NPS team indicated that a morning report 
aggregated the number of telephone calls processed daily, the number of examinations 
processed - successfully and unsuccessfully, the number of transcripts requested and 
distributed, and the number of diplomas distributed. The morning report was manually 
collated. However, that process had been terminated and no records available from which 
to extrapolate historical impact. 

c. As-Is Process Model 

The As-Is process model documents the business area analysis of the 
current system. Graphic representations helped to summarize the results. The business 
area analysis of SSD was documented with a decomposition diagram and several node tree 
diagrams. These diagrams illustrate the functional decomposition of activities performed 
to administer student activity records in MCIAIS. The process model is provided as 
Appendix B. 

Manual activities within a process model add definition to the business 
system architecture. The manual processes however, can lead to discontinuity in the 
information and technical architecture. A large number of manual activities prevents 
accurate measurement of throughput and associated cost. This is one reason for targeting 
their elimination during reengineering. 

C. REENGINEERING THE AS-IS PROCESS MODEL 

Reengineering approaches and methodologies were discussed in Chapter IV. This 
section addresses the business environment leading to the selection of Harrington’s 
Business Process Inn ovation (BPI)as the reengineering methodology best suited for MCI. 
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Following the assessment, the BPI methodology is discussed as it applies to the current 
processes at MCI. The section concludes with a summary that leads to the development of 
the To-Be process model. 

1. Assessing the Reengineering Environment 

The information gathered during the enterprise analysis and development of the 
As-Is model was critical to understanding MCI’s business environment and the urgency 
with which reengineering may be applied. 

a. Reengineering Category 

Initially, the authors believed MCI fell into the crisis reengineering 
category. Prior to August 1996, the Commandant of the Marine Corps urged MCI to 
improve its level of customer service. Executive level interest and support were keen and 
funding was readily available. Some organizational restructuring was already underway 
and demonstrating marked improvements. In spite of the quick fixes, however, the need 
for formal reengineering of the information system still existed. 

Culturally, MCI is a traditional organizational hierarchy. As a result, MCI 
exhibited great resistance to notions of radical transformation. For example, MCI was not 
interested in suggestions of outsourcing the shipping process to a commercial package 
delivery company or moving to Internet accessible, on-line enrollment procedures for 
customers. It was evident from the first interviews that radical changes would not receive 
the support or continuity of personnel necessary to carry radical modernization to fruition. 
The incremental approach of the life-cycle reengineering category was seen as the best fit 
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based upon the expected turnover of key management personnel and procurement 
schedule of the replacement system architecture. 

b. Reengineering Ideals 

An assessment of the reengineering ideals provide perspective on MCI 
business environment and the degree of commitment to modernization. 

Process Orientation- MCI retains much of the outdated management 
perspective of the industrial age. It is primarily task organized in an assembly line manner. 
A major reason for this is the prevalence of combat arms personnel staffing key 
management billets. Transition to the information age is evident and a new information 
system a key element Another key element is a paradigm shift from task orientation to 
process orientation and process improvement. 

Three distinctive processes are apparent at MCI. The first is information 
gathering and distribution: maintaining a course catalog of over 300 items, maintaining 
the addresses and course history of over one million students, and maintaining 
examination question banks and answers for over 160 courses. The second process is 
warehousing and shipping of catalog items. The third process is course development and 
writing of text books and associated material. Many reengineering opportunities exist with 
this wide range of processes. Other initiatives, outside the scope of this project, should 
address the MCI logistics and course development processes, leaving the information 
gathering and distribution the only function available for reengineering as part of this 
project. This function is performed by the Student Services and Information Systems 
Management Divisions at MCI. 
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Ambition - The degree of ambition is reflected in the number of protected 
processes. It is also reflected by the amount of resistance encountered when proposing to 
reengineer a candidate process. This became obvious during the circulation of the SSD 
As-Is process model. 

Rule-breaking - The effort to reduce business rules often requires an 
understanding of existing rules in place. MCI made a genuine effort to document their 
current business rules in force. It was discovered during the process that many of the rules 
were made so that the programmer could code them. While business rules standardize 
operating procedures, complicated conditions proved difficult for Marine programmers to 
understand and implement. As a result, considerable effort was put into eliminating 
business rules attached to student enrollments. 

Creative use of information technology - Information technology (IT) 
plays a key role in BPR. MCI demonstrated considerable interest in this ideal. But due to 
limited exposure, not all personnel are aware of IT opportunities or their potential 
benefits. Additionally, the acquisition of IT resources, for the military in general, is often a 
lengthy process and limits the more immediate results that can be achieved. 

The delays associated with procurement of IT resources may provide the 
time for the reluctant, or undecided, stakeholders to “buy-into” the reengineering effort. 
This buy-in may facilitate the integration of all the process owners as effective participants 
in the modernization effort. In the meantime, a continuous process improvement approach 
is necessary to complement the cultural environment. For these reasons, the selection of 
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Harrington’s BPI methodology was determined to be the best fit for applying business 
process reengineering techniques to MCI. 

2. Reengineering Implementation 

Harrington’s BPI methodology addresses five phases: organizing for 
improvement, understanding the process, streamlining, measurement and control, and 
continuous improvement The authors application of these five phases discovered that 
much of the work was already performed. Further investigation found evidence that an 
external consultant had analyzed MCI and many improvements were already implemented. 

Phase I, organizing for improvement. This phase provides structure and continuity 
to a modernization effort by staffing reengineering roles. MCI had already created a 
Process Improvement Requirements (PER) Section and formalized its importance by 
incorporating it into tl e organizational structure. The deputy director filled the role as 
leader. As MCI’s number two position, the deputy director is in the ideal position to 
influence reluctant employees to embrace the change program, create organization vision, 
and ensure managerial and financial continuity. He briefed the Commandant, the 
Commanding General, MCCDC, and the Director, Training and Education Division to 
muster financial support for the modernization plan. A steering committee was already 
formed as the MCIAIS Redesign Team. The members included the Deputy Director, 
Executive Director, PMED chief, OSD chief, SSD chief. Logistics chief, and the 
Computer Systems Analyst. A czar, with information systems management experience 
and previous assignments as SSD and MISD chief, was in place. Department chief filled 
the role as process owner. An external consultant had been involved once before and the 
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addition of the NPS team provided a detached perspective as well as technological 
expertise not possessed by anyone else in the MCI. The personnel assigned to MCI were 
ready for change. 

Staffing the reengineering roles outlined above have the greatest impact on the 
success of the reengineering effort at MCI. The transient nature of a military unit makes it 
difficult to sustain long term projects. Personnel rotate through billets within a military 
organization every one to three years and not all of the personnel rotate at the same time. 
This staggered rotation lends stability to long term projects in a traditional, non-military 
organization by allowing personnel and policy continuity. However, the strict hierarchical 
structure of a military unit may have a destabilizing effect on long-term projects as project 
teams and objectives are influenced by the more hierarchically senior individuals. For 
example, the modernization project began in July 1995 and significant progress was made. 
In May 1997, a new deputy director was assigned and with modernization well underway, 
enthusiasm waned. The new deputy director is tasked with other time consuming duties 
and priorities that pre vent him from continuing the reengineering leadership of his 
predecessor. Other reengineering roles at MCI have experienced similar dynamics. 

The reengineering czar that began the project retired in June 1997 and was 
replaced by a civilian contracted project manager. This will enhance the project’s potential 
for success because the project manager has military and database migration experience 
and is trained in both project management and reengineering techniques. The steering 
committee composition also changed as members were replaced. 
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The SSD and MISD process owner are the only roles that remained intact 
throughout the research portion of the modernization project. The addition of an Internet 
Interface process owner expected in August 1997 is viewed by the authors as a plus for 
the potential success of the modernization as the replacement has a masters degree in 
Information Technology Management and is already familiar with the MCI modernization 
project. 

MCI organizational structure is also unduly influenced more by the government 
worker placement policy and practice than by sound reengineering principles. In June 
1996, the PIR Section was formed with two civilian employees. Their former MCI 
positions were eliminated as a result of downsizing. These employees were transferred to 
MCI’s operations department and chartered to “improve the MCI process.” Steeped in 
TQL tradition, the “process improvement team” had no concept of process modeling, 
work flow analysis, or other techniques necessary to conduct reengineering. 

With the exception of the project manager, the process improvement team and 
other members filling reengineering roles, have no formal reengineering technique training. 
To ensure project success at MCI emphasis must be placed on filling all of the billets on 
the reengineering team with competent and motivated personnel. 

Phase n, understanding the process. This phase focuses on data collection and 
modeling. The process owners had a thorough understanding of what their processes did 
and what they wanted their processes to do. The objective of the NPS team was to 
document this awareness. Much of the data collection had already been accomplished, 
customer interviews, task breakdown worksheets, flow charts, mission statements and 
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models, by the previous consultant. The authors believe that most of the models were not 
presented to MCI in an expected form, to their understanding and without tools for 
continued maintenance. 

Phase ID, streamlining. This phase concentrates on the reengineering effort. 
Process elimination traditionally accounts for a significant contribution to reengineering 
benefits. When applying the reengineering principles and analyzing the As-Is process 
model looking to eliminate non-value-added processes, it was discovered that due to the 
sequential nature of SSD tasks, many of the non-value-added tasks had already been 
removed. For example, reporting the number of DP-37s, phone calls, or transcript 
requests processed on a morning report. No one used this information and it was manually 
intensive to collate. 

Most processes had already been simplified. For example, the enrollment 
procedures for Marines through the unit diary, and pre-packaging a new DP-37 with 
course material for faster distribution have reduced customer response time. Additionally, 
SSD functions are sequential because subsequent tasks depend upon completion of the 
previous ones. Figure 24 illustrates this sequence. As and example, SSD enrolls students 
in courses; tests their comprehension by issuing and grading examinations; stores student 
course history; and issues transcripts. Transcripts cannot be issued without course history 
and exams cannot be graded without enrollment. 

The remaining reengineering effort had to focus on automating manual tasks and 
methods to capture data only one time. The most dramatic impact on this effort will be 
made by implementing the network accessible relational database technology, MCIAIS-II. 
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Figure 24. SSD Sequential Process Flow. 

The response time of user interaction will be reduced by eliminating multiple entry 
requirements. Graphical user interface (GUI) will be updated and more responsive to user 
requirements. The database itself will be more flexible - easier to modify and adjust with 
the more frequent changes commonly encountered in today’s business environment. A 
relational database provides facilitates flexible query and customized report generating 
capability. 

One method to take advantage of a new relational database is redistribution of 
selected batch processes. Batch processing is currently used at MCI to update MCIAIS 
with transactions from the grading program, unit diary transactions downloaded from 
MCTFS, and input through daily transactions. Other batch processes generate transaction 
files for yet other batch process to execute: the grading program creates a diploma print 
file, a completion certificate file and an error listing file; enrollments and standard material 
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requests create a mailing label file; another program creates a motivation card file. Finally, 
there are batch processes used to produce the output of transaction files: printing mailing 
labels for material distribution, printing UARs in the monthly cycles, copying the diploma 
file to disk for the registrar to print. These type of transactions are necessary because of 
the different paper stock the output requires: mailing labels on a standard 3 Vi inch by 1 Vi 
inch self-adhesive label, motivation cards and completion certificates are on preprinted 
stock, diplomas require laser quality print on heavy gauge stock. 

Running the grading program “on demand,” would allow SSD greater control of 
their own schedule and possible facilitate faster processing of examinations, diplomas, and 
error listing. “On demand” processing could prove very productive for the UAR 
processing. Over 1500 UARs are generated in the monthly close out cycle. Responses to 
the UAR are received over a short period of time and not much time is available to 
process all responses prior to the next cycle. The distribution and response load could be 
distributed more evertiy over the month. The SSD clerk would have more time for 
processing before the next cycle. 

Private sector businesses rely heavily on its efficient processing of customer input. 
That is how orders are received, goods are sold and income is generated. Not only are 
requests for enrollment processed through A single point of entry, but also grading 
examinations, requests for materials or information, and processing of unit reconciliation 
reports. If MCI charged customers for their products and depended on the processed 
payments, using current procedures, they would go broke. 
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Modern technology has enabled businesses to cut costs by moving to a paper-less 
work environment. MCI should take advantage of IT to follow suit. A concentrated effort 
should be directed at utilizing current IT solutions to replace the manual tasks involved 
with obtaining customer input by concentrating of the process principle of “capture 
information once, at the source.'’’ Alternate modes of enrollment should be utilized. 

Student services realized a significant improvement by enrolling Marines through the unit 
diary. The burden of data entry was shifted from student services clerk to the unit diary 
clerk and MISD batch processing. Similar improvement can be achieved by utilizing the 
Internet for enrollment, status query, material requests, examinations, and changes to 
student information. Many of the same processes can be achieved interactive voice 
response systems (IVRS). (Currid, 1994) 

More efficient processing of electronic mail can be realized by combining a filtering 
agent and establishing standards for electronic mail sent to the MCI OMB. Most filtering 
agents allow the user to specify specific words that appear in the “From” or “Subject” 
fields of the e-mail. On that precept, rules can be designed to sort incoming e-mail’s 
subject line and distribute to the appropriate section’s OMB for processing. Subject line 
standards should be published in the next revision of the Marine Corps Institute 
Procedures Manual c r an MCI Internet Web Page. The Web Page can even pre-format the 
message for the customer. Filtering agent technology is rapidly advancing, such that 
enrollments or queries could be done by e-mail and a response generated by the computer 
without human intervention. (Currid, 1994) 
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An Internet based web page can used to publish the course, the Marine Corps 
Institute Procedures Manual, telephone contact directory, as well as a Frequently Asked 
Question (FAQ) library. Customer access to this information could reduce the number of 
telephone calls entertained by the immediate assist clerks. 

Digitized course materials and electronic distribution upon accepted enrollment 
could reduce the production, warehouse and inventory overhead. This requires further 
analysis of the available and required bandwidth, as well as customer access. A deployed 
Marine, soldier, sailor or airman may have limited or no access to the Internet or a PC to 
complete a course in digitized form. 

Development of a Unit MCI module that automated the manual task of local 
record keeping would earn praise from training NCO around the Marine Corps. Presently, 
the training NCO manually prepares a R-5 card when a Marine wants to enroll in a course 
or program. The form is forwarded to the unit diary clerk for data entry into MCTFS. 
Automating the form such that it populated the unit MCI database and generated either a 
standard electronic mail or batched and transmitted to MCI could bypass using MCTFS 
and the unit diary for enrollment. Include a reconciliation application in the module and 
UAR could be done with minimal human intervention and improved efficiency. 

For those activities that must use paper, apply the process principle: “ Perform 
work where it makes the most sense ” suggesting, mail sorting and segregation could be left 
to the postal service prior to distribution within MCI. Utilizing the last four digits of the 
nine digit zip code could contribute to faster distribution of incoming mail. Faster 
distribution of customer input translates to more parallel processing. Automated mail 
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handling equipment is another solution that could accelerate distribution of incoming mail, 
as well as capture and measure the throughput. 

Integrating the Logistics Department’s inventory and automating additional 
logistics functions into MCIAIS would improve material distribution and improve SSD’s 
visibility of student material. The use of bar-coding can monitor the progress of material 
through the packaging and distribution cycle. Shipping status would become available to 
the SSD clerk when responding to student inquiries. Monitoring the distribution cycle can 
also identify other candidates activities for improvement. 

Phase IV, measurement and control. This phase implements a system to control 
the process for continued improvements (Harrington, 1991). This builds on the process 
model by adding performance measures for the reengineered processes. Ideally, the 
process modeling technique and CASE tool selected support reporting the performance 
criteria. DoD and the FPI methodology emphasize using activity based costing as one 
measurement method. Additionally, responsibility for model maintenance should be 
established for continuity. 

The PER Section is ideally suited for the responsibility of model maintenance. It is 
staffed by civilian personnel which is an uncommon advantage for a military activity. Such 
staffing can provide necessary continuity to monitor performance. The personnel are well 
trained in Total Quality fundamentals. They need additional experience with process 
modeling, process improvement methodology, activity based costing, and information 
technology opportunities. Their lack of experience in these areas detract credibility from 
their assignment in the PIR Section. 
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The 1DEF0 modeling technique for process modeling allows for representation of 
mechanisms, personnel, equipment, etc. in each process. Process modeling can represent 
performance measures. Performance measures describe the work done and the results of 
that activity (Turney, 1991). Modeling can eliminate the seemingly wasted effort in manual 
efforts. In addition to EDEFO modeling, BPWin® can integrate activity based costing 
categories and represent totals within the model. Activity based costing provides two 
dimensions to use in process reengineering: cost assignment view and process view. 
Together they can direct MCI toward a more efficient product and service strategy. 
Incorporating activity based costing will help MCI realize additional benefits in process 
measurement for continuous improvement in their modernization effort. 

Phase V, continuous improvement. This phase emphasizes continuous monitoring 
of improved processes for continued excellence. This depends on maintenance of the 
process models by monitoring the reengineered processes and periodically evaluating 
performance measures. MCI must develop a data and process model, maintain it, and use 
it for the benefits the models provide. Part of the justification for migrating from the 
legacy system was based on the lack of code documentation. A new system can experience 
the same fate if not pioperly maintained. Additionally, the models enable prototyping 
which can reduce anxiety of implementing changes without adequate testing. 

3. Reengineering Summary 

Despite the numerous opportunities identified in the previous section, 
reengineering the As-Is model focused on migrating the current functionality to MCLAIS- 
II. The lengthy acquisition process and costs associated with many of the IT solutions 



145 



would not be achievable prior to the expected delivery of the new computer. The objective 
shifted to producing a process model that reflected the information system it would 
immediately represent and an information system model the designers could use to 
program. 

The To-Be process model did not include activity based costing (ABC) because 
there was insufficient data made available with which to model. The author’s felt that 
ABC would further complicate a process model, a concept not easily appreciated outside 
of MISD. There was already enough new knowledge required and a new costing paradigm 
might put the models on a shelf never to be found. 

With the majority of processes already streamlined and non-value-added processes 
dependent on automated equipment not available, reengineering efforts turned to 
minimizing redundant data entry, integrating similar processes and data sharing. These 
three problem areas are well suited for information technology solutions. Specifically, 
these three areas can all be improved with implementation of a relational database 
application. In effect automating tasks by eliminating the need to re-key a customer’s data 
when fulfilling multiple requests or bouncing between screens. Other reengineering 
benefits can be reaped by redistributing and eliminating some of the batch processes 
performed by MIS. Moving the functions of grading, UAR file generation, and diploma 
printing to SSD workstations allow the user to execute the programs “on demand.” 

D. TO-BE PROCESS MODEL FOR SSD 

The To-Be process model represents the redesigned business activity of the 
student service support business area. It resulted from reengineering selected processes of 
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the As-Is process monel. The implementation of an automated information system based 
on relational database technology, a dramatic reduction in the number of primitive level 
processes was realized. Despite the reduced number of processes, SSD customer service 
response time will decrease because of the data sharing capability. SSD can be further 
improved by incorporating a portion of the MISD As-Is processes into the SSD To-Be 
model. As-Is MISD functions that could be run from SSD workstations “on demand” 
include: the grading application, UAR file generation, and diploma printing. 

1. To-Be Model Details 

All of the activities depicted in the SSD process model are prefixed with “T.” The 
entire node tree diagram is too large to print as one document so it was divided into 
several diagrams representing various levels. The remaining model details must be gleaned 
from careful study of the model components included as Appendix C. 
a. Business Area Decomposition 

Functional decomposition of the To-Be model started at the business area 
level from the enterprise analysis. It reconstructed the decomposition of the As-Is model 
using the reengineered processes. A total of 1 14 activities and 120 arrows were identified 
and defined. The business area Student Service Support was decomposed six levels down 
to primitive processes. The first level identified four functions: CUSTOMER 
SERVICING, STUDENT ACTIVITY SERVICING, GRADING, and REGISTRAR 
SERVICING. Figure C-l, Appendix C is a node tree diagram of all the activities of 
Student Service Support. 
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The CUSTOMER SERVICING - T1 function was decomposed into two 
processes: OBTAIN CUSTOMER INPUT and PROVIDE UNIT ACTIVITY. A significant 
number of processes were reduced by taking advantage of the capabilities of the relational 
database. Instead of representing each different type of processing for changing or 
servicing a student’s record, a CALL arrow was used to one of the processes represented 
under activity T2. The As-Is activity representing the Conversant AVRS was removed 
from SSD processes and moved to MISD. Maintaining AVRS is strictly a database 
administration process. Servicing a Marine Corps unit reconciliation processes were 
reduced with the CALL procedure mentioned above and a process to represent the ability 
to request UAR “on demand” was added. 

The STUDENT ACTIVITY SERVICING -T2 function was decomposed 
into five processes: PROCESS ENROLLMENT, PROCESS STATUS REQUEST, 
CHANGE STUDENT INFORMATION, PROCESS ADMINISTRATIVE ACTION and 
PROCESS REQUEST FOR MATERIAL. All processes representing a change input to 
change a student’s record is represented in this function. The graphical user interface 
should lead the user to the desired action much quicker than possible in the As-Is model. 
Transaction codes are no longer required as most relational database have an inherent 
transaction code log. An measurement feature can be incorporated to indicate the 
student’s mode of requesting the change (i.e., telephone, e-mail, walk-in, UAR, etc.). 
Material request processing was automated by eliminating the use of manual forms for 
“Request for Material” and “Off-line Material” requests. Routing for approval can be 
accomplished by the DBMS application if still required. 
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The GRADING -T3 function was decomposed into four functions: 
PROCESS DP-37’ S, PROCESS HAND GRADED EXAMS, RUN GRADING 
PROGRAMS and PROCESS OPSCAN ERRORS. This process still has a lot of manual 
processes represented. The OCR readable exams issued and the two different sized forms 
was a limiting factor. An “on demand” process was added to facilitate running the 
program to grade exams data collected from the scanned DP-37s. The “on demand” 
facility provides an added feature to work the OPSCAN error listing “on demand” as well. 

The REGISTRAR SERVICING - T4 function was decomposed into two 
functions: ISSUE DIPLOMA and ISSUE TRANSCRIPT. An “on demand” feature was 
added to allow the user to print diplomas at any time following the execution of the 
grading program. The transcript production reflects automated transcript generation based 
on user provided information for the transcripts requested by former students whose data 
has been archived on microfiche. The transcript application would be programmed to draw 
all student information from MCIAIS to complete a transcript from an internal template. 

b. To-Be Process Model 

The To-Be process model documents the business system model for the 
new information system of MCI. Graphic representations helped to summarize the result. 
The To-Be process model consists of a functional decomposition diagram (Table C-2, 
Appendix C), an activity dictionary (Table C-3, Appendix C), an arrow dictionary (Table 
C-4, Appendix C), the node tree diagram (Figure C-l, Appendix C), the context diagram 
(Figure C-2, Appendix C) and an IDEFO kit (Figures C-3 - C-37, Appendix C) presenting 
the process decomposition down to the primitive levels. 
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Not ail of the manual activities could be eliminated. They remain in the 
process model to provide complete definition to the business system architecture. Future 
continuous improvement efforts should focus on reengineering principles to further reduce 
their persistence and increase process efficiency. Additionally, shifting to a process 
improvement oriented accounting approach, such as activity based costing, would help 
realize the true cost of delaying further process improvements. 

2. Information System Model 

The SSD information system model represents what data the system manipulates, 
captures, and stores in the MCI To-Be process model. While this thesis focuses on the 
first two stages of the information engineering methodology, a proof-of-concept prototype 
is an objective of the MCI modernization project. Design and construction of the 
information model is beyond the scope of this thesis, however, information system 
prototype development requires a different view of the data and process models. As a 
result, an information model was developed to facilitate prototype development. As noted 
in Chapter V, there a e three parts to the model: (1) DFDs depicting information system 
process decomposition, (2) definitions of all of the symbols on each of the diagrams, and 
(3) process specifications at the primitive process level. The information system model 
serves as a bridge between the data and process modelers and the prototype developer. 
a. DFDs 

As noted in Chapter V, the first step in developing an information model is 
to remove the manual processes from the To-Be model. The SSD system context diagram. 
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shown in Figure 25, shows the SSD System and the outside entities. A context diagram is 
the highest level of the DFD. 
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Figure 25. SSD System DFD: Context Diagram. 

Functional decomposition techniques, described in Chapter V, are applied 
to the context diagram to create the next level of the DFD, diagram 0. Figure 26 shows 
the five major automated processes of the SSD information system model: (P-1P) Display 
Catalog, (P-2P) Update Marine Information, (P-3P) Interface with Unit Diary, (P-4) 

Order Material, and (P-5) Service Student. Each of these processes is further decomposed 
to the primitive level. The prototype developer uses these diagram in conjunction with the 
symbol dictionary and process specifications to code the prototype. 

All of the processes hierarchy numbers depicted in the SSD information 
system model are prefixed with “P” for process. All of the data store hierarchy numbers 
depicted in the SSD information system model are prefixed with “D” for data store. The 
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Figure 26. SSD System DFD: Diagram 0. 
suffix “P” indicates primitive level processes. Figures 27 and 28 illustrate two of the 
primitive level DFD diagrams for the SSD processes illustrating DFD techniques. The 
remaining decomposition diagrams are too large for inclusion in this thesis but may be 
viewed in NPS-SM-97-006: Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Final Report (Kamel 
et al., 1997). 



Data stores are also decomposed in a way similar to processes. The 
technique was devised to aid developers and analysts working with large numbers of 
database tables. The same parent/child relationships that apply to processes also apply to 
data stores and its use prevents cluttered and confusing diagrams. Figure 29 shows how 
the SSD database, MCLAIS-2, is decomposed into subordinate data stores. This first 
subordinate decomposition diagram is a logical grouping of data entities. Decomposition 
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Figure 27. SSD System DFD: (P-1P) Display Catalog. 



UD Acknowledgment 




Figure 28. SSD System DFD: (P-5.9.3P) Determine Pass/Fail. 



153 




Figure 29. MCIAIS-2 Data Store Decomposition. 



continues until actual data model table names are identified and assigned a hierarchy 
number. Figure 30 illustrates how the logical data store (D-1.4) Logical Student History is 
decomposed further into five actual database tables: (D-1.4. 1) STUD_CRS_EXAM_X, 
(D- 1.4.2) STUD_CRS_X, : (D- 1.4.3) STUD_PRG_X, : (D- 1.4.4), 

STUD_CRS_TRAN_ X (D- 1.4.5) STUD_PRG_TRAN_X. 
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Figure 30. SSD System DFD: (D-1.4) Logical Student History Data Store 

Decomposition. 



b. DFD Symbol Dictionary 

The DFD decomposition diagrams are accompanied by the DFD symbol 
dictionary. Without the dictionary, it is difficult for a prototype developer to distinguish 
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data table names with the precision necessary to code the prototype. For example, two 
data table names in the data model are ERJR_CODES and ERR_LIST Although the be 
names may be distinctive to the data modeler, implementation coding and debugging may 
frustrating to the programmer because a data element may be coded to read from the 
incorrect data table. 

The DFD symbol dictionary is arranged alphabetically and contains an 
entry for each of the 214 symbols that appear in the diagrams. Each page of the dictionary 
contains columnar headings for symbol name and hierarchical number (data flows are not 
assigned a number), type of symbol, description, and the DFD diagram number where 
the symbol appears. In addition to alphabetical appearance, font type and size is used as to 
further aid dictionary use. Processes are listed in all capital letters, and data flow are listed 
in ten pitch title case. Figure 31 is an excerpt from the dictionary. The entire dictionary 
may be viewed in NPS-SM-97-006: Analysis, Design, and Prototype Implementation of 
a Contemporary Information System for the Marine Corps Institute, Final Report (Kamel 
et al., 1997). 

c. Process Specifications 

Process specifications summarize the data input, output, and logic of each 
of the primitive processes. Only primitive level processes are included as parent processes 
are an aggregated collection of the children's inputs, outputs, and logic. A typical process 
specification for a primitive level process is shown in Figure 32. Process specifications for 
entire model may be viewed in NPS-SM-97-006: Analysis, Design, and Prototype 
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DFI) Symbol Dictionary 



Name Symbol Type Definition DFI) 



CrsOnHandQty 


Data Flow 


Data element definitions can be founa in the 
Attribute Definitions Report (Exhibit 5, Appendix A) 


P-4 4P 


Current Course Request 


Data Flow 


Course requested, that is current version 


P-5 10. IP 
P-5 10.2P 


Current Program Request 


Data Flow 


Program requested that is current version 


P-5. 10. IP 
P-5.10. 2P 


CUST (D- 1 .5 1) 


Data Store 


CustSSnJD + State + CustLastName + 
CustFirstName + CustMidlnit + CustDSN + 
CustCommNo + CustAddrl + CustAddr2 + CustCity 
+ CustZip 


D-1.5 
P-4 IP 
P-4 2P 


Customer Identity 


Data Flow 


Customer Instance 


P-4 IP 
P-4 2P 
P-4 3P 


Customer Information 


Data Flow 


Name, rank, SSN, grade, service component, 
address, and telephone number 


context 

P-0 

P-4.2P 


Customer Instance 


Data Flow 


CustSSnJD + State + CustLastName + 
CustFirstName + CustMidlnit + CustDSN + 
CustCommNo + CustAddrl + CustAddr2 + CustCity 
+ CustZip 


P-4 IP 
P-4 2P 


Customer Order 
Information 


Data Flow 


Customer Information + Material Request + Invoice 
Data 


P-0 


Customer Request 




High level bundle of inquiries or other requests from 
a customer: status, information, transcript request, 
request for material, etc. 


context 


Customer SSN 


Data Flow 


SSN of customer 


P-4 IP 


DETERMINE IF STUDENT 
MEETS PREREQUISITES 
(P-5.10.3P) 


Process 


Compares the requested course or program 
prerequistes to the student's course history. 


P-5 10 


DETERMINE OF 
STUDENT IS IN DATA 
BASE (P-5 IP) 


Process 


Checks for SSN match to a student SSN in the MCI 
student data base. 


P-5 


DETERMINE PASS/FAIL 
(P-5.9.3P) 


Process 


Compares number student s exam correct answers 
to the minimum passing score for tnat exam 


P-5 9 


•Diploma 


Data Flow 


The certificate issued to the student for passing all 
of the course exams that make up a program The 
diploma is accompanied by a letter indicating 
transript information for the program and summary 
of the included courses. 


P-5 9 
P-5.9. 6P 


DISENRQLL STUDENT 
(P-5.6P) 


Process 


Disenrolls a student from a course he/she is enrolled 
in 


P-5 


Disenrolled 


Data Flow 


Data element definitions can be found in the 
Attribute Definitions Report (Exhibit 5. Appendix A) 


P-5.6P 



Data element definitions can be found in 

the Attribute Definitions Report SSD Process Model 

(Exhibit 5, Appendix A) Exhibit 28, Appendix B 

— 3 — 



Figure 31. Excerpt From DFD Symbol Dictionary. 
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Process Specification Form 
Process Number: P-5.9.6P 

Process Name: print diploma 

Input Data Flow: 

Program Completion Information 
Student Identity 
AD Marine Student Address 
Marine Reservist Address 
NonMarine Student Address 
Output Data Flow: 

Diploma 
Invoice Instance 
PrgDipIssueDate 
TranJD + SP_TransDate_ID 
Module Logic: 

For each program completion 
get Student Identity 

appropriate address 

UPDATE Student Program History 
CREATE Invoice Instance 

format & print Diploma 

Figure 32. Process Specification Form for (P-5.9.6P) Print Diploma. 

Implementation of a Contemporary Information System for the Marine Corps Institute, 

Final Report (Kamel et al., 1997). 

3. Application Mapping 

A Process versus Data Entity (CRUD) Matrix was developed from the To-Be 
process model. The CRUD Matrix maps the process activities to the data base tables and 
is included as Figure C-38 of Appendix C. The CRUD Matrix validates: 1) that all of the 
data model entities have a purpose in the process model, and 2) that the data model 
contains only the entities required by the process model. 

Clustering the CRUD Matrix results in the Clustered CR Matrix. Every “C\ “U”, 
and “D” was replaced with a “C” as described in Chapter III. BPWin® did not perform an 
automated clustering. A manual procedure was necessary. All of the BPWin entities 
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representing transient data created in the process model were removed from the CRUD 
Matrix. All of the manual processes were also removed as well since there was not a data 
entity with which to associate. The remaining relationships were arranged to form groups. 

Analysis of the groupings that result from the Clustered CR Matrix reveal four 
SSD applications: Student Servicing, Unit Servicing, Grading, and Registrar. A fifth 
application, Executive Summary' Information, was identified to provide management with 
the adhoc query capability achievable with a relational database. The logical and physical 
distribution of the five applications throughout SSD is described in another team members 
thesis (Evers, Jr., 1997). The CR Matrix is included as Figure C-39, Appendix C. Table 5, 
details the capability of each of the applications. 



Application 


Capability 


Student Servicing 


On-line Course Catalog Access, Enrollment, Disenrollment, 
Course History Access, Order Materials 


Unit Servicing 


On-line Course Catalog Access, Enrollment, Disenrollment, 
Course History Access, Order Materials , UAR Generation 


Grading 


Grading, Course History, Student History 


Registrar 


On-line Course Catalog Access, Course History, Transcript 
Generation 


Executive Summary 
Information 


On-line Course Catalog Access, Predefined SQL Query 
Capability 



Table 5. Recommended Application Capability. 
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VIII. SUMMARY, RECOMMENDATIONS, AND CONCLUSIONS 
This chapter provides a summary of the thesis as well as recommendations and 
conclusions. First it addresses the research questions and objectives presented in Chapter 
1. Next it summarizes the enterprise analysis methodology, process modeling, and a 
recommended reengineering plan for the Student Services Department at MCI. 
Additionally, it includes implementation recommendations and some anticipated obstacles. 
The chapter concludes with suggested topics for future study and conclusions. 

A. ACHIEVEMENT OF RESEARCH OBJECTIVES AND QUESTIONS 

This research is the result of a year long project commissioned by MCI to develop 
the architecture and supporting migration plan to transition from a closed, non-relational 
system to an open, client/server based relational database management system (DBMS). 
The research and development was conducted by a six member team at the Naval 
Postgraduate School. The objectives of this research project were achieved: enterprise 
analysis was conducted, business area analysis of the SSD was conducted, data and 
process models were developed, the process model was reengineered, an information 
system was designed and, a proof of concept prototype was produced. If implemented, the 
modernization plan will make the SSD more efficient and effective at providing service to 
their customers. 

In the course of this project, the research questions posed in Chapter I were 

answered. These questions and their answers are outlined below. 

• Can a process model be developed to reflect the current business process of 
the Student Services Department of the Marine Corps Institute (MCI)? 
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A detailed As-Is process model was created using EDEFO modeling techniques for 
the Student Services Department of MCI. The model diagrams and the data dictionary are 
included in NPS Technical Report NPS-SM-97-006: Analysis, Design, and Prototype 
Implementation of a Contemporary Information System for the Marine Corps Institute, 
Final Report (Kamel et al., 1997). The model conforms to the DoD standard for process 
modeling and can serve as a baseline process model for future reengineering efforts. 

• Can the business process of the Student Services Department of MCI be 
reengineered? 

The SSD business process can only be reengineered to a limited extent due to the 
nature of MCI work flow as well as budgetary constraints. There are no tasks in the SSD 
process that can be eliminated because of the sequential nature of the SSD work flow. 
However, reengineering benefits can be gained from implementation of a shared relational 
database that eliminates redundant data entry, publication of the course catalog on the 
Internet, and development of on-line enrollment forms to further increase the efficiency 
and effectiveness of the Student Services Department. 

• Can a prc c ess model be developed to reflect the reengineered business process 
of the Student Services Department of MCI? 

A To-Be process model was created using IDEFO modeling techniques for the 
Student Services Department of MCI. The model diagrams and the data dictionary are 
included in NPS Technical Report NPS-SM-97-006: Analysis, Design, and Prototype 
Implementation of a Contemporary Information System for the Marine Corps Institute, 
Final Report (Kamel et al., 1997). The model conforms to the DoD standard for process 



162 



modeling and can serve MCI as an example and first iteration of an ongoing reengineering 
effort. 

• What BPP. methodology is most suitable for reengineering the Student 
Services Department of MCI? 

Of the four BPR methodologies surveyed, Hammer and Champy’s Business 
Process Reengineering, Thomas Davenport’s Process Innovation, H. James Harrington’s 
Business Process Improvement, and DoD’s Functional Process Improvement (FPI), no 
one methodology was identified as a perfect fit for reengineering the SSD. Each 
methodology has strengths and weaknesses that effect its use in the MCI business 
environment. Elements of all four methodologies were applied with particular emphasis on 
the business process improvement methodology of H. J. Harrington. 

• What CASE tool is most suitable for reengineering the Student Services 
Department of MCI? 

Although BPwin® was the CASE tool selected and used for process modeling. 
System Architect/BPK Professional would have been a better choice because it offered 
one central repository for both data and process model metadata and a more versatile 
DFD graphics capability. Despite the advertised compatibility of BPwin® with its sibling 
data modeling tool ERwin®, initial metadata transfer between the two tools was less than 
perfect. During the course of the project, it was necessary to request a software patch 
from the vendor so that data model definitions could be imported into BPwin®. 

• Can a CRUD diagram be developed to support the BPR of the Student 
Services Department of MCI? 

A CRUD matrix for the SSD was generated and clustered. The CRUD matrix, 
containing 44 data entities and 1 13 functional activities was clustered manually because 
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none of the reviewed CASE tools had that capability. BPwin® did have a CRUD matrix 
module that generated the CRUD matrix on a Microsoft Excel spreadsheet but needed to 
be refined and adjusted manually because of the model’s large size. 

B. SUMMARY OF PROCESS MODEL DEVELOPMENT 

Process model development was conducted according to the first two stages of 
James Martin’s information engineering methodology: enterprise level analysis and 
business area analysis. Within these two stages, information about the organization is 
gathered and analyzed with matrices and diagrams to produce an As-Is model. The As-Is 
model is then reengineered to produce the To-Be model. The DoD standard IDEFO 
modeling technique is used for both process models. This process takes some time to 
complete but ensures sufficient detail for sound analysis. 

C. IMPLEMENTATION RECOMMENDATIONS 

The following recommendations are suggested for reengineering implementation at 



MCI. 

• Examine the set of high level matrices developed in this study that show the 
relationship between entities, functions, organization units and locations. Use 
the information obtained from the matrices to review the mission, functions, 
goals, organization structure, and the information needed to run MCI business. 

• View reengineering at MCI as an ongoing effort and supported by the 
information systems architectures, methodologies and tools. 

• Establish a priority and schedule for developing, refining, and reengineering the 
business area process, beyond the student services functions, according to the 
business areas identified in this study. 

• Utilize a single database to facilitate data sharing among MCI departments, 
streamline processes, facilitate automation, eliminate data redundancy, and 
improve customer service. 
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• Utilize Activity Based Costing (ABC) methodology to identify cost drivers in 
SSD. Like most DoD activities, capturing and distributing cost data is not a 
common practice. 

• Facilitate further SSD reengineering with the development and collection of 
measures of effectiveness (MOE) and measures of performance (MOP). 
Properly chosen MOPs and MOEs are critical to the evaluation of process 
improvements and will help identify other candidate processes for 
improvement. 

• Consider the development of a Training NCO Interface Application. This 
application would essentially manage the Training NCO’s R-5 file on a local 
database and would reduce manual data input for the new system. 

D. ANTICIPATED OBSTACLES 

Organizational issues such as fiscal limitations, politics, cultural bias, and top-level 
leadership support must be considered. IS managers must be able to face these challenges 
effectively, or the technical issues discussed in this work will have little impact on the 
success of future system deployment. These issues are beyond the scope of this thesis. 

E. FUTURE RESEARCH REQUIREMENTS 

Many inform: non technology solutions have reengineering applicability to the 
business areas at MCI. However, before they are blindly applied, a thorough business area 
analysis, similar to the one conducted in this thesis on the Student Services Department, 
must be conducted on each of the remaining business areas. The two business areas with 
the most interaction with SSD are the logistics and the program and course development 
departments. 

F. CONCLUSIONS 

To deploy and operate effectively and efficiently in the information age, DoD 
organizations must take a serious look at the way they conduct business and implement 
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their processes. A de‘ ailed process analysis of a business area provides an opportunity for 
redesigning/reengineering to reduce costs, improve efficiency, and better meet the needs 
of customers. The de /elopment of an enterprise wide model and detailed data and process 
business area models are the necessary building blocks for developing and deploying 
information systems that support the mission and objectives of the organization. 

Adopting a methodology based on the development of the three models 
(business/process, data and technology) is extremely important for successful redesign at 
both enterprise and business application area levels. The development of a detailed As-Is 
business process model is necessary to thoroughly understand the processes of the 
different departments of MCI and for successful reengineering. There are a variety of 
modeling techniques available, as well as numerous CASE tools which support these 
models. Managers face the dilemma of which tools and strategies to select when dealing 
with the migration fro n legacy systems to open, relational information systems. This 
research supports the use of an information engineering methodology coupled with IDEF 
modeling techniques and a suitable CASE tool which supports synchronization of process 
and data models. This approach will allow for successful migration to open, client/server 
information systems. 
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APPENDIX A. BPR METHODOLOGIES 



This appendix contains details of the business process reengineering methodologies discussed in 
Chapter III. 

a. Hammer , Champy, and Stanton 

For more information consult the following books: 

Michael Hammer, James Champy, Reengineering the Corporation : A Manifesto for Business Revolution , 
HarperBusiness, New York: 1994. 



Michael Hammer, Steven A. Stanton, The Reengineering Revolution : A Handbook , HarperBusiness, New 
York: 1995. 



b. Thomas Davenport 

From Thomas H. Davenport, Process Innovation: Reengineering Work through Information 

Technology , Harvard Business School Press, Boston: 1993. 

Davenport's Five Phases of Process Innovation 

PHASE I: IDENTIFY PROCESSES FOR INNOVATION 

Key activities: -Enumerate major processes 

-Determine process boundaries 

-Assess strategic relevance of each process 

-Render high-level judgements of the “health" of each process 

-Qualil / the culture and politics of each process 

PHASE II: IDENTIFY CHANGE LEVERS 

Key activities: -Identify potential technological and human opportunities for process change 

-Identify potentially constraining technological and human factors 
-Research opportunities in terms of application to specific processes 
-Determine which constraints will be accepted 

PHASE III: DEVELOP PROCESS VISION 

Key activities: -Assess existing business strategy for process directions 

-Consult with process customers for performance objectives 
-Benchmark for process performance targets and examples of innovation 
-Formulate process performance objectives 
-Develop specific process attributes 

PHASE IV: UNDERSTAND EXISTING PROCESSES 

Key activities: -Describe the current process flow 

-Measure the process in terms of the new process objectives 
-Assess the process in terms of the new process attributes 
-Identity problems with or shortcomings of the process 
-Identify short-term improvements in the process 
-Assess current information technology and organization 
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PHASE V: DESIGN AND PROTOTYPE THE NEW PROCESS 
Key activities: -Brainstorm design alternatives 

-Assess feasibility, risk, and benefit of design alternatives and select the preferred 
process design 

-Prototype the new process design 
-Develop a migration strategy 

-Implement new organizational structures and systems 
c. H. James Harrington 

From H. James Harrington, Business Process Improvement: The Breakthrough Strategy for 
Total Quality, Productivity , and Competitiveness , McGraw-Hill, Inc.: New York, 1991. 

Harrington's Five Phases of Business Process Improvement (BPI) 



PHASE I: ORGANIZING FOR IMPROVEMENT 



Objective: 

Activities: 



To ensure success by building leadership, understanding, and commitment 

1. Establish Executive Improvement Team (EIT) 

2. Appoint a business process improvement (BPI) champion 

3. Provide executive training 

4. Deveiop an improvement model 

5. Communicate goals to employees 

6. Review business strategy and customer requirements 

7. Select the critical process 

8. Appoint process owners 

9. Select the process improvement team (PIT) 



PHASE II: UNDERSTANDING THE PROCESS 

Objective: To understand all the dimensions of the current business process 

Activities: 1. Define the process scope and mission 

2. Define process boundaries 

3. Provide team training 

4. Develop a process overview 

5. Define customer and business measurements and expectations for the process 

6. Flow diagram the process 

7. Collect cost, time, and value data 

8. Perform process walk-throughs 

9. Resolve differences 

10. Update process documentation 



PHASE III: STREAMLINING 



Objective: 

Activities: 



To improve tr»e efficiency, effectiveness, and adaptability of the business process 

1. Prov.de team training 

2. Identify improvement opportunities: 

Errors and rework High cost 

Poor quality Long time delays 

Backlog 

3. Eliminate bureaucracy 

4. Eliminate no-value-added activities 

5. Simplify the process 

6. Reduce process time 

7. Error-proof the process 

8. Upgrade equipment 
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9. Standardize 

10. Automate 

1 1 . Document the process 

12. Select the employees 

13. Train the employees 



PHASE IV: MEASUREMENT AND CONTROL 



Objective: 

Activities: 



To implement a system to control the process for ongoing improvement 

1. Develop in-process measurements and targets 

2. Establish a feedback system 

3. Audit the process periodically 

4. Establish a poor-quality cost system 



PHASE V: CONTINUOUS IMPROVEMENT 



Objective: 

Activities: 



implement a continuous improvement process 

1. Qualify the process 

2. Perform periodic qualification reviews 

3. Define and eliminate process problems 

4. Evaluate the change impact on the business and on customers 

5. Benchmark the process 

6. Prov-de advanced team training 



d. DoD Functional Process Improvement (FPI) 

From DoDInst 8020. 1M 

A 25-step methodology has been developed that will take an FPI project team from developing a strategic 
plan to the development of a final functional economic analysis (FEA) or business case. It is important to 
note that an organization may have already completed some of the steps of the methodology through other 
means such as Total Quality Management (TQM) initiatives or an Information Systems Planning (ISP) 
effort. The information generated as a result of these efforts will greatly reduce the amount of time 
necessary to complete the FPI project. 

Strategic Planning (Steps 1-4) 

1. Secure Executive Commitment for Functional Process Improvement Project 

-Conduct executive briefings 

- Concepts and principles of FPI 

- DoD policy and requirements 

- Functional management process (DoD 8020. 1-M, Ch 2) 

- FPI Management Framework 

- Intended expected benefits 

- Project management considerations 

-Arrange site visits to organizations committed to TQM/FPI 
-Develop Charter defining scope and extent of project 
-Secure explicit commitment to launch project 

2. Confirm/Defme Functional Mission 

-identify higher authority mandates/constraints 

- Review DoD relevant policy 

- Review applicable DoD directives (8000 series) 

- Review DMRD requirements/constraints 
-Identify current resource availability 
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-Develop statement of values and beliefs 

-Develop mission statement 

-Test mission statement for consistency and efficacy 

- Mission statement is consistent with higher authority mandates/constraints 

- Mission statement can be accomplished with current resource availability 

- Mission statement embodies stated values and beliefs 

3. Develop Strategic Pla*v 

-Identify functional Customers 

- External 

- Internal 

-Establish critical customer requirements and needs 

- Analysis of current service levels 

- Customer surveys and interviews 

- Value-chain analysis (customer products and services) 

-Prioritized customer requirements and needs 

-Identify/rank current and potential competitors (alternative sources) 

-Test customer requirements and needs against mission statement 
-Resolve mission/customer requirements and needs inconsistencies 
-Develop prioritized list of customer requirements that will be met 
-Develop functional goals for satisfying customer requirements 

- Develop vision statement (Guiding Principle(s)) 

- Identify goals for key results areas 

- Customer satisfaction 

- Productivity 

- Innovation 

- Resource conservation 

- Management development and performance 

- Employee development and performance 

- Public responsibility 

- Develop critical success factors 
-Test goals stater ients against mission, values and beliefs 

4. Conduct Strategic/Customer Benchmarking and Best Practices Analysis 

-Conduct Competitive analysis 
-Examine available benchmarking databases 
-Interview customers 
-Interview functional area experts 
-Research literature 

-Validate goals statements against benchmarking best practices data 
-Refine statement of goals 

Business Planning (Steps 5-8) 

5. Develop Business Plan 

-Develop measurements for each stated goal 

-Identify product and services features for each customer requirement 
-Develop specific objectives for satisfying customer requirements 
-Develop perfor lance targets for each objective 
-Resolve goals, ubjectives and product features anomalies 
-Develop/refine quality matrices 

6. Identify, Understand and Document Current Business Processes 

-Conduct/valick j- business systems planning (BSP)/Information Systems Planning (ISP) data 
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-List business processes 

-List current organization structures 

-Develop process/organization matrix 

-Develop product feature/process matrix 

-Evaluate/analyze/prioritize relative process performance 

-Select function^ process for FPI action 

7. Document the Functional Architecture 

-Document the mission of the functional area 

-Document the mission of the subordinate functional activity(s) 

-Relate functional area and activity(s) to Enterprise Architecture 
-Describe the business process(s) (of activity) subject to process improvement 
-Identify all organizational impacts for the business process(s) 

-Establish scope of effort for improving the business process(s) 

-Identify and charter the Functional Activity Program Manager 
-Restate/revise the parameters for process improvement 

- Process objectives 

- Performance measures and methods 

- Performance targets 

- Current performance variances to targets 
-Develop the Functional Management Strategy 

-Secure OSD Principle Staff Assistant approval to proceed 

8. Initiate Functional Process Improvement Project 

-Develop project plan 

- Develop project scope 

- Develop work breakdown structure (WBS) 

- Develop organization breakdown structure (OBS) 

- Select process improvement action team (PAT) 

- Identity project resources and facilities 

- Develop resource assignment matrix (RAM) 

- Develop initial schedules 

- Deve’op initial cost estimates 
-Conduct initial raining 

-Develop project execution management plan 
-Launch project 

Process Analysis [Problems/Qpportunitiesl (Steps 9-1 3) 

9. Review, Revise or Develop AS-IS Activity Models for Selected Process 

-Model AS-IS process/activities 
-Model AS-IS activity process flow 
-Review process models 
-Update process models 
-Validate process models 

10. Review, Revise or Develop AS-IS Data Models for Selected Process 

-Model AS-IS data models 
-Review data models 
-Update data models 
-Validate data models 
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1 1 . Perform Activity-Based Costing Study of AS-IS Process 
-Review metrics, measures and methods 
-Conduct activity-based costing 

- Analyze activities 

- Gather cost data 

- Trace costs to activities 

- Establish output measures 

- Analyze costs 
-Conduct time-line analysis 

12. Conduct Cost/Process Benchmarking and Best Practice Analysis with respect to AS-IS Models 

-Develop benchmarking strategy 

- Identify features, functions and services 

- Identify operating, administrative and personnel cost categories 

-Select and screen comparison companies 
-Collect data 

- Proprietary information 

- Physical observation 

- Trade data 
-Develop conclusions 
-Refine performs nee targets 

13. Perform Functional Process Improvement Analysis 

-Review objectives and measures 

- Produce the "right" products and services 

- Consistency of performance 

- Timeliness and customer response 

- Appropriate cost (competitive) 

- Safety, morale, job satisfaction 

- Good citizenship (affect on other organizations) 

- Customer relationships (flexibility, accommodation) 

-Perform techniques to discover problems and improvement opportunities 

- Pareto analysis 

- Histograms 

- Cause and effect diagrams 

- Scatter diagrams 

- Statistical process control 

- Process simulation 

-Identify quick fixes 
-Conduct what-d analysis 
-Conduct scenario analysis 
-Analyze cost divers 

- Economies of scale 

- Learning curve effects 

- Capacity utilization 

- Linkages (value-chain analysis) (overhead) 

- Interrelationships (other business processes) 

- Integration (make us buy analysis) 

- Timing (just-in-time analysis) 

- Policy (constraints, mandates) 

- Location (geographical analysis) 
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- Institutional factors (environmental considerations) 

-Analyze quality drivers 

- Inputs (data and materials) 

- People (process personnel) 

- Equipment (machines, computers, systems) 

- Methods (procedures, rules, regulations, training) 

- Materials (supplies, tools) 

- Environment (including location) 

- Outputs (data, products and services) 

- Administrative functions 

- External agencies and higher authority 

- Feedback (control systems, measurements) 

-Prepare Improvement Opportunity Analysis Report 
-Conduct in-progress review (IPR) 

-Make IPR changes to AS -IS models and improvement report 
-Publish AS -IS report 

Process Design/Justification (Steps 14-21) 

14. Develop Process Improvement Initiative Packages (four classes) 

-Class 1: Package quick fix improvement initiatives 

-Class 2: Package improvement initiatives that have little or no impact on existing 
information systems 

-Class Package improvement initiatives that have major impacts on existing 
inform^ bon systems 

-Class 4 Package improvement initiatives that will require new information systems 
(new technology) 

-Rank improvement initiatives within class 

15. Develop Potential High-Level To-Be Activity and Data Models 

-Develop/revise the "vision” of the To-Be environment 
-Select To-Be concept 

-Select improvement packages for high-level modeling 
-Perform high-level modeling 

- Activity models 

- Data models 

- Process models 

16. Revise Improvement Initiative Packages Based on To-Be Models 

-Develop clear statement of problem/opportunity 

-Revise improvement initiative packages based on high-level To-Be models 
-Develop assumptions and constraints 

-Determine imp : mentation alternatives for each selected improvement initiative package 

17. Select Initiative Package Based on Economic Analysis of Potential Alternatives 

-Perform economic analysis 

- Collec? cost/benefit data for each alternative 

- Perform Risk Adjusted Discounted Cash Flow (RADCF) analysis 

- Perform sensitivity analysis 

- Document non-quantitative considerations 
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18. Develop Detailed To-Be Activity and Data Models Based on Selected Initiative Package 

-Develop detailed To-Be models 

- Activity models 

- Data models 

- Process models 
-Perform simulation 

-Perform functional level integration analysis 
-Document information systems support considerations 

19. Develop Preliminary Functional Economic Analysis (FEA) Decision Package 

-Summarize functional strategic plan 

-Identify functional activity performance measures and targets 

-Document activity improvement program 

-Document economic analysis of proposed improvement initiatives 

20. Develop Data Management and Technical Management Plans 

-Develop functional activity information systems strategy 
-Analyze data systems 

-Document recommended changes and redirection 

21 . Develop Final Functional Economic Analysis (FEA) Decision Package 
-Document savings, benefits and risks of selected alternatives 
-Develop project white papers 
-Develop integrated financial plan 

-Update Planning, Programming and Budgeting System (PPBS) 

-Define approval requirements 
-Obtain policy approvals 
-Obtain FEA approval 

Improvement Execution Plan (Steps 22-25) 

22. Develop Project/Action/Transition Plans 

-Develop integrated implementation plan 
-Develop new goals and strategies 
-Establish new performance targets 
-Develop implementation schedule 
-Determine implementation resource requirements 
-Establish implementation team 
-Designate implementation steering committee 
-Design project implementation controls 

23. Conduct Executive Presentations 

-Prepare executive briefing 
-Conduct executive briefing 

-Review recommended changes to the Project/ Action/Transition Plans 
-Revise Project/ Action/Transition Plans 
-Produce project implementation plan 

24. Execute Approved FEA 

-Develop design specifications 
-Develop prototype/pilot 
-Manage change 

-Conduct IPR for steering committee 
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-Produce project execution report 

25. Evaluate Results, Up^iate Baseline Data and Document Lessons Learned 
-Monitor industry trends and developments 
-Evaluate results-of improvement action 
-Establish criteria for future improvement projects 
-Document lessons learned 
-Update baseline models (convert To-Be to AS-IS) 
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APPENDIX B. AS-IS PROCESS MODEL 



This appendix contains the components of the As-Is Process Model 
documentation. Table B-l is a list of tables and figures as they appear in the appendix. 



Number 


Title 


Table B-2 


As-Is Process Model Decomposition Diagram 


Figure B-l 


As-Is Process Model Node Tree Diagram (SSDO): 
3 Levels - Provide Student Services 


Figure B-2 


As-Is Process Model Node Tree Diagram (SSD1): 
4 Levels - Obtain Customer Input 


Figure B-3 


As-Is Process Model Node Tree Diagram (SSD2): 

4 Levels - Make Changes to Student’s Course Activity 
Record 


Figure B-4 


As-Is Process Model Node Tree Diagram (SSD3): 
4 Levels - Grade Student’s Exams 


Figure B-5 


As-Is Process Model Node Tree Diagram (SSD4): 
4 Levels - Process Unit Activity Reports 


Figure B-6 


As-Is Process Model Node Tree Diagram (SSD5): 
4 Levels - Process Request for Material 


Figure B-7 


As-Is Process Model Node Tree Diagram (SSD6): 
4 Levels - Process Requests for Registrar Action 



Table B-l. List of To-Be Process Model Components. 
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Activity Number 


Activity Name 


SSDO 


PROVIDE STUDENT SERVICES 


SSD1 


OBTAIN CUSTOMER INPUT 


SSD1.1 


PROCESS INCOMING PHONE CALLS 


SSD1.1.1 


PROCESS CONVERSANT CALLS 


SSD1. 1.1.1 


PROVIDE CONVERSANT INSTRUCTIONS 


SSD1. 1.1.2 


PROCESS CONVERSANT INQUIRY 


SSD1.1. 1.2.1 


OBTAIN TOUCHTONE SSN 


SSD1.1. 1.2.2 


OBTAIN TOUCHTONE COURSE NUMBER 


SSD1.1. 1.2.3 


PROVIDE CONVERSANT COURSE STATUS 


SSD1. 1.1.3 


EXIT CONVERSANT SYSTEM 


SSD1. 1.1.4 


TRANSFER CALL TO MCI STAFF 


SSD1. 1.1.5 


PROVIDE ADDITIONAL CONVERSANT 
INSTRUCTIONS 


SSD1.1.2 


PROCESS MCI OPERATOR- ASSISTED CALLS 


SSD1. 1.2.1 


PROCESS PHONE REQUEST FOR STATUS/INFO 


SSD1. 1.2.1. 1 


INPUT PHONE CUSTOMER'S SSN 


SSD1.1.2.1.2 


PROVIDE PHONE CUSTOMER STATUS 


SSD1. 1.2.2 


PROCESS PHONE CHANGE TO STUDENT’S 
INFORMATION 


SSD1.1.2.2.1 


PROCESS PHONE REQUEST FOR ENROLLMENT 


SSD1. 1.2.2. 1.1 


IDENTIFY PHONE ENROLLMENT CUSTOMER 


SSD1. 1.2.2. 1.1.1 


OBTAIN SSN OF PHONE ENROLLMENT 
CUSTOMER 


SSD1. 1.2.2. 1.2 


INPUT SSN OF PHONE ENROLLMENT CUSTOMER 


SSD1. 1.2.2. 1.2 


DETERMINE DESIRED COURSE OF PHONE 
ENROLLMENT CUSTOMER 


SSD1. 1.2.2. 1.2.1 


OBTAIN DESIRED COURSE NUMBER OF PHONE 
ENROLLMENT CUSTOMER 


SSD1. 1.2.2. 1.2.2 


INPUT DESIRED COURSE NUMBER OF PHONE 
ENROLLMENT CUSTOMER 


SSD1.1.2.2.1.3 


VERIFY PHONE ENROLLMENT CUSTOMER 
INFORMATION 


SSD1. 1.2.2. 1.3.1 


VALIDATE PHONE ENROLLMENT CUSTOMER 
INFORMATION 


SSD1. 1.2.2. 1.3.2 


INPUT MISSING PHONE ENROLLMENT 
CUSTOMER INFORMATION 


SSD1.1.2.2.1.3.3 


VALIDATE PHONE ENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 


SSD1.1.2.2.1.4 


ENTER TRANSACTION CODE FOR PHONE 
ENROLLMENT 


SSD1. 1.2.2 i.4.1 


INPUT TC-A FOR PHONE ENROLLMENT 
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Activity Number 


Activity Name 


SSD1. 1.2.2. 1.4.2 


UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH PHONE ENROLLMENT 


SSD1.1. 2.2.2 


PROCESS PHONE REQUEST TO CHANGE 
INFORMATION 


SSD1. 1.2.2.2.1 


IDENTIFY CUSTOMER REQUESTING PHONE 
CHANGE 


SSD 1.1. 2. 2.2. 1.1 


OBTAIN SSN OF PHONE CHANGE CUSTOMER 


SSD1. 1.2.2.2.1.2 


INPUT SSN OF PHONE CHANGE CUSTOMER 


SSD1.1.2.2.2.2 


DETERMINE INFORMATION TO CHANGE BY 
PHONE 


SSDl.1.2.2.2.2.1 


PROCESS PHONE CHANGE TO STUDENT'S NAME 
(NON-ACTIVE DUTY USMC) 


SSD1.1.2.2.2.2.1.1 


OBTAIN CHANGE TO STUDENT'S NAME BY 
PHONE (NON-ACTIVE DUTY USMC) 


SSD1.1.2.2.2.2.1.2 


INPUT CHANGE TO STUDENT'S NAME BY PHONE 
(NON-ACTIVE DUTY USMC) 


SSD1.1.2.2.2.2.2 


PROCESS PHONE CHANGE TO STUDENT'S 
ADDRESS (NON- ACTIVE DUTY USMC) 


SSD1.1.2.2.2.2.2.1 


OBTAIN CHANGE TO STUDENT'S ADDRESS BY 
PHONE (NON-ACTIVE DUTY USMC) 


SSD1.1.2 2.2. 2. 2.2 


INPUT CHANGE TO STUDENT'S ADDRESS BY 
PHONE (NON-ACTIVE DUTY USMC) 


SSD1.1.2.2.2.2.3 


PROCESS PHONE CHANGE TO STUDENT’S RANK 
(NON- ACTIVE DUTY USMC) 


SSD1. 1.2.2. 2.2. 3.1 


OBTAIN PHONE CHANGE TO STUDENT’S RANK 
(NON-ACTIVE DUTY USMC) 


SSD1.1.2.2.2.2.3.2 


INPUT PHONE CHANGE TO STUDENT'S RANK 
(NON-ACTIVE DUTY USMC) 


SSD1. 1.2.2.2.3 


ENTER TRANSACTION CODE FOR PHONE 
CHANGE 


SSD1.1.2.2.2.3.1 


INPUT TC-D FOR CHANGE BY PHONE 


SSD1.1.2.2.2.3.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
PHONE CHANGE 


SSD1.1.2.2.3 


PROCESS PHONE REQUEST FOR EXTENTTON 


SSD1.1.2.2.3.1 


IDENTIFY PHONE EXTENTION CUSTOMER 


SSD1.1.2.2.3.1.1 


OBTAIN SSN OF PHONE EXTENTION CUSTOMER 


SSD1.1. 2.2.3. 1.2 


INPUT SSN OF PHONE EXTENTION CUSTOMER 


SSD1.1.2.2.3.2 


DETERMINE DESIRED COURSE OF PHONE 
EXTENTION CUSTOMER 


SSD1. 1.2.2. '..2.1 


OBTAIN DESIRED COURSE NUMBER OF PHONE 
EXTENTION CUSTOMER 


SSD1.1. 2.2.3. 2.2 


INPUT DESIRED COURSE NUMBER OF PHONE 
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Activity Number 


Activity Name 




EXTENTION CUSTOMER 


SSD1.1.2.2.3.3 


VERIFY PHONE EXTENTION CUSTOMER 
INFORMATION 


SSD1. 1.2.2. 3.3.1 


VALIDATE PHONE EXTENTION CUSTOMER 
INFORMATION 


SSD1.1.2.2.3.3.2 


INPUT MISSING PHONE EXTENTION CUSTOMER 
INFORMATION 


SSD1.1.2.2.3.3.3 


VALIDATE PHONE EXTENTION CUSTOMER 
MEETS COURESE PREREQUISITES 


SSD1.1.2.2.3.4 


ENTER TRANSACTION CODE FOR PHONE 
EXTENTION CUSTOMER 


SSD1.1.2.2.3.4.1 


INPUT TC-E FOR PHONE EXTENTION 


SSD1.1.2.2.3.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
PHONE EXTENTION 


SSD1.1. 2.2.4 


PROCESS PHONE REQUEST FOR 
DISENROLLMENT 


SSD1.1.2.2.4.1 


IDENTIFY PHONE DISENROLLMENT CUSTOMER 


SSD1.1.2.2.4.1.1 


OBTAIN SSN OF PHONE DISENROLLMENT 
CUSTOMER 


SSD1.1.2.2.4.1.2 


INPUT SSN OF PHONE DISENROLLMENT 
CUSTOMER 


SSD1.1.2.2.4.2 


DETERMINE DESIRED COURSE OF PHONE 
DISENROLLMENT CUSTOMER 


SSD1. 1.2. 2.4.2. 1 


OBTAIN DESIRED COURSE NUMBER OF PHONE 
DISENROLLMENT CUSTOMER 


SSD1.1.2.2.4.2.2 


INPUT DESIRED COURSE NUMBER OF PHONE 
DISENROLLMENT CUSTOMER 


SSD1. 1.2.2. 4.3 


VERIFY PHONE DISENROLLMENT CUSTOMER 
INFORMATION 


SSD1. 1.2. 2.4.3. 1 


VALIDATE PHONE DISENROLLMENT CUSTOMER 
INFORMATION 


SSD1.1.2.2.4.3.2 


INPUT MISSING PHONE DISENROLLMENT 
CUSTOMER INFORMATION 


SSD1.1.2.2.4.3.3 


VALIDATE PHONE DISENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 


SSD1. 1.2. 2.4.4 


ENTER TRANSACTION CODE FOR PHONE 
DISENROLLMENT 


SSD1.1.2.2.4.4.1 


INPUT TC-H FOR PHONE DISENROLLMENT 


SSD1.1.2.2.4.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
PHONE DISENROLLMENT 


SSD1.1. 2.2.5 


PROCESS PHONE REQUEST FOR RE- 
ENROLLMENT 
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Activity Number 


Activity Name 


SSD1.1.2.2.5.1 


IDENTIFY PHONE RE-ENROLLMENT CUSTOMER 


SSD1.1. 2.2.5. 1.1 


OBTAIN SSN OF PHONE RE-ENROLLMENT 
CUSTOMER 


SSD1. 1.2.2.5. 1.2 


INPUT SSN OF PHONE RE-ENROLLMENT 
CUSTOMER 


SSD1.1.2.2.5.2 


DETERMINE DESIRED COURSE OF PHONE RE- 
ENROLLMENT CUSTOMER 


SSD1.1. 2.2.5. 2.1 


OBTAIN DESIRED COURSE NUMBER OF PHONE 
RE-ENROLLMENT CUSTOMER 


SSD1.1.2.2.5.2.2 


INPUT DESIRED COURSE NUMBER OF PHONE RE- 
ENROLLMENT CUSTOMER 


SSD1. 1.2.2.5.3 


VERIFY PHONE RE-ENROLLMENT CUSTOMER 
INFORMATION 


SSD1.1.2.2.5.3.1 


VALIDATE PHONE RE-ENROLLMENT CUSTOMER 
INFORMATION 


SSD1.1.2.2.5.3.2 


INPUT MISSING PHONE RE-ENROLLMENT 
CUSTOMER INFORMATION 


SSD1.1.2.2.5.3.3 


VALIDATE PHONE RE-ENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 


SSD1. 1.2.2.5 4 


ENTER TRANSACTION CODE FOR PHONE RE- 
ENROLLMENT 


SSD1.1. 2.2.5. 4.1 


INPUT TC-R FOR PHONE RE-ENROLLMENT 
CUSTOMER 


SSD1. 1.2.2 5.4.2 


UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH PHONE RE-ENROLLMENT 


SSD1.1.2.3 


PROCESS PHONE REQUEST FOR MATERIAL 


SSD1.1. 2.3.1 


DETERMINE MATERIAL PHONE CUSTOMER 
NEEDS 


SSD1. 1.2.3. 1.1 


VERIFY PHONE CUSTOMER'S INFORMATION 


SSD1. 1.2.3. 1.2 


VALIDATE PHONE CUSTOMER'S MATERIAL 
REQUEST 


SSD1.1.2.3.2 


PROCESS STANDARD REQUESTS FOR MATERIAL 
FOR PHONE CUSTOMER 


SSD1. 1.2. 3.2.1 


VALIDATE PHONE CUSTOMER’S REQUEST 


SSD1.1.2.3.2.2 


VERIFY AVAILABILITY OF MATERIAL 
REQUESTED BY PHONE 


SSD1.1.2.3.2.3 


ENTER TRANSACTION CODE FOR MATERIAL 
REQUESTED BY PHONE 


SSD1.1.2.3.2.3.1 


ENTER TC-I FOR PHONE REQUEST FOR 
DUPLICATE EXAM 


SSD1. 1.2.3 2.3.2 


ENTER TC-P FOR PHONE REQUEST FOR 
DUPLICATE COURSE/PROGRAM 
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Activity Number 


Activity Name 


SSD1.1.2.3.2.3.3 


ENTER TC-T FOR PHONE REQUEST FOR 
INDIVIDUAL GENERIC DP-37 


SSD1.1.2.3.2.3.4 


ENTER TC-Y FOR PHONE REQUEST FOR 
DUPLICATE DIPLOMA/COMPLETION 
CERTIFICATE 


SSD1.1.2.3.3 


PREPARE "REQUEST FOR MATERIAL" FORM FOR 
PHONE CUSTOMER 


SSD1.1. 2.3.3. 1 


OBTAIN BLANK "REQUEST FOR MATERIAL" 
FORM 


SSD1.1.2.3.3.2 


WRITE PHONE CUSTOMER'S NAME ON 
"REQUEST FOR MATERIAL" FORM 


SSD1.1.2.3.3 3 


WRITE PHONE CUSTOMER'S SSN ON "REQUEST 
FOR MATERIAL" FORM 


SSD1. 1.2.3.3 4 


WRITE PHONE CUSTOMER'S ADDRESS ON 
"REQUEST FOR MATERIAL" FORM 


SSD1.1.2.3.3.5 


WRITE PHONE CUSTOMER’S DESIRED ITEM 
NAME ON "REQUEST FOR MATERIAL" FORM 


SSD1.1.2.3.3.6 


WRITE PHONE CUSTOMER'S DESIRED QUANTITY 
ON "REQUEST FOR MATERIAL" FORM 


SSD1.1. 2.3.4 


PREPARE "OFF-LINE REQUEST" FORM FOR 
PHONE CUSTOMER 


SSD1.1.2.3.4.1 


OBTAIN BLANK "OFF-LINE REQUEST" FORM 


SSD1.1.2.3.4.2 


WRITE PHONE CUSTOMER'S NAME ON "OFF-LINE 
REQUEST" FORM 


SSD1. 1.2. 3.4.3 


WRITE PHONE CUSTOMER'S SSN ON "OFF-LINE 
REQUEST" FORM 


SSD1.1.2.3.4.4 


WRITE PHONE CUSTOMER’S ADDRESS ON "OFF- 
LINE REQUEST" FORM 


SSD1.1.2.3.4.5 


WRITE PHONE CUSTOMER'S ITEM NAME ON 
"OFF-LINE REQUEST" FORM 


SSD1.1.2.3.4.6 


WRITE PHONE CUSTOMER'S DESIRED QUANTITY 
ON "OFF-LINE REQUEST" FORM 


SSD1.2 


SORT INCOMING U.S. MAIL 


SSD1.2.1 


SEGREGATE STUDENT COURSE INPUT 


SSD1.2.1.1 


SEGREGATE FEEDBACK FORMS 


SSD1.2.1.2 


SEGREGATE GENERIC DP-37s 


SSD1.2.1.3 


SEGREGATE PRE-SLUGGED DP-37s 


SSD1.2.1.4 


SEGREGATE ESSAY EXAM/LESSONS 


SSD1.2.2 


SEGREGATE UNIT INPUT 


SSD1.2.2.1 


SEGREGATE UNIT ACTIVITY REPORTS 


SSD1.2.2.2 


SEGREGATE ENROLLMENTS 


SSD1.2.3 


SEGREGATE MAILED CUSTOMER INQUIRIES 
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Activity Number 


Activity Name 


SSD1. 2.3.1 


SEGREGATE WRITTEN REQUEST FOR STATUS 


SSD1.2.3.2 


SEGREGATE WRITTEN REQUEST FOR CHANGE 
TO CUSTOMER STATUS 


SSD1.2.3.3 


SEGREGATE WRITTEN CHANGE TO CUSTOMER 
INFORMATION 


SSD1.2.3.4 


SEGREGATE WRITTEN REQUEST FOR MATERIAL 


SSD1.3 


SORT INCOMING E-MAIL 


SSD1.3.1 


PRINT E-MAIL MESSAGES 


SSD1.3.2 


SEGREGATE E-MAIL REQUEST FOR STATUS / 
INFO 


SSD1.3.3 


SEGREGATE E-MAIL REQUEST FOR CHANGE TO 
CUSTOMER STATUS 


SSD1.3.4 


SEGREGATE E-MAIL REQUEST FOR MATERIAL 


SSD1.3.5 


SEGREGATE E-MAIL UAR RESPONSE 


SSD1.3.6 


PROCESS INDIVIDUAL E-MAIL RECEIVED 


SSD1.4 


PROCESS WALK-IN CUSTOMERS 


SSD1.4.1 


PROCESS WALK-IN REQUEST FOR STATUS 


SSD1.4.1.1 


INPUT SSN OF WALK-IN CUSTOMER 


SSD1.4.1.2 


PROVIDE WALK-IN CUSTOMER STATUS 


SSD1.4.2 


PROCESS WALK-IN REQUEST FOR CHANGE TO 
CUSTOMER STATUS / INFORMATION 


SSD1.4.3 


PROCESS WALK-IN REQUEST FOR MATERIAL 


SSD2 


MAKE CHANGES TO STUDENT'S COURSE 
ACTIVITY RECORD 


SSD2.1 


PROCESS REQUEST FOR ENROLLMENT 


SSD2.1.1 


IDENTIFY ENROLLMENT CUSTOMER 


SSD2.1. 1.1 


OBTAIN SSN OF ENROLLMENT CUSTOMER 


SSD2.1.1.2 


INPUT SSN OF ENROLLMENT CUSTOMER 


SSD2.1.2 


DETERMINE TYPE OF ENROLLMENT 


SSD2.1.2.1 


PROCESS REQUEST FOR REGULAR 
ENROLLMENT 


SSD2. 1.2.1. 1 


VERIFY INFORMATION OF REGULAR 
ENROLLMENT CUSTOMER 


SSD2.1.2.1.1 1 


VALIDATE INFORMATION OF REGULAR 
ENROLLMENT CUSTOMER 


SSD2.1.2.1.1.2 


INPUT MISSING INFORMATION OF REGULAR 
ENROLLMENT CUSTOMER 


SSD2.1.2.1.1.3 


VALIDATE REGULAR ENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 


SSD2.1.2.1.2 


DETERMINE COURSE OF REGULAR 
ENROLLMENT CUSTOMER 
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^Activit^Nam^ 


SSD2. 1.2. 1.2.1 


OBTAIN COURSE OF REGULAR ENROLLMENT 
CUSTOMER 


SSD2. 1.2. 1.2.2 


INPUT COURSE CODE OF REGULAR 
ENROLLMENT CUSTOMER 


SSD2.1.2.2 


PROCESS REQUEST FOR BULK ENROLLMENT 


SSD2.1.2.2.1 


VERIFY INFORMATION OF BULK ENROLLMENT 
CUSTOMER 


SSD2.1. 2.2.1. 1 


VALIDATE INFORMATION OF BULK 
ENROLLMENT CUSTOMER 


SSD2. 1.2.2. 1.2 


INPUT MISSING INFORMATION OF BULK 
ENROLLMENT CUSTOMER 


SSD2.1.2.2.1.3 


VALIDATE BULK ENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 


SSD2.1.2.2.2 


DETERMINE COURSE OF BULK ENROLLMENT 
CUSTOMER 


SSD2. 1.2.2. 2.1 


OBTAIN COURSE OF BULK ENROLLMENT 
CUSTOMER 


SSD2.1.2.2.2.2 


INPUT COURSE OF BULK ENROLLMENT 
CUSTOMER 


SSD2.1.2.3 


PROCESS REQUEST FOR ADMINISTRATIVE 
ENROLLMENT 


SSD2.1. 2.3.1 


VERIFY INFORMATION OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 


SSD2.1.2.3. 1 .1 


VALIDATE INFORMATION OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 


SSD2. 1.2.3. 1.2 


INPUT MISSING INFORMATION OF 
ADMINISTRATIVE ENROLLMENT CUSTOMER 


SSD2.1.2.3.1.3 


VALIDATE ADMINISTRATIVE ENROLLMENT 
CUSTOMER MEETS COURSE PREREQUISITES 


SSD2.1.2.3.2 


DETERMINE COURSE OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 


SSD2.1.2.3.2.1 


OBTAIN COURSE OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 


SSD2.1.2.3.2.2 


INPUT COURSE CODE OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 


SSD2. 1.2.4 


PROCESS REQUEST FOR RE-ENROLLMENT 


SSD2.1. 2.4.1 


VERIFY INFORMATION OF RE-ENROLLMENT 
CUSTOMER 


SSD2. 1.2.4. 1 1 


VALIDATE INFORMATION OF RE-ENROLLMENT 
CUSTOMER 


SSD2.1.2.4.1.2 


INPUT MISSING INFORMATION OF RE- 
ENROLLMENT CUSTOMER 
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Activity Number 


Activity Name 


SSD2. 1.2.4. 1.3 


VALIDATE RE-ENROLLMENT CUSTOMER MEETS 
COURSE PREREQUISITES 


SSD2.1. 2.4.2 


DETERMINE COURSE OF RE-ENROLLMENT 
CUSTOMER 


SSD2. 1.2.4. 2.1 


OBTAIN COURSE OF RE- ENROLLMENT 
CUSTOMER 


SSD2. 1.2.4.2.2 


INPUT COURSE OF RE-ENROLLMENT CUSTOMER 


SSD2.1.2.5 


PROCESS REQUEST FOR SPECIAL RE- 
ENROLLMENT 


SSD2.1.2.5.1 


VERIFY INFORMATION OF SPECIAL RE- 
ENROLLMENT CUSTOMER 


SSD2. 1.2.5. 1.1 


VALIDATE INFORMATION OF SPECIAL RE- 
ENROLLMENT CUSTOMER 


SSD2. 1.2.5. 1.2 


INPUT MISSING INFORMATION OF SPECIAL RE- 
ENROLLMENT CUSTOMER 


SSD2. 1.2.5. 1.3 


VALIDATE SPECIAL RE-ENROLLMENT 
CUSTOMER MEETS COURSE PREREQUISITES 


SSD2.1. 2.5.2 


DETERMINE COURSE OF SPECIAL RE- 
ENROLLMENT CUSTOMER 


SSD2.1.2.5.2.1 


OBTAIN COURSE OF SPECIAL RE-ENROLLMENT 
CUSTOMER 


SSD2.1.2.5.2.2 


INPUT COURSE OF SPECIAL RE-ENROLLMENT 
CUSTOMER 


SSD2.1.3 


ENTER TRANSACTION CODE FOR ENROLLMENT 


SSD2.1.3.1 


INPUT TC-A FOR REGULAR ENROLLMENT 


SSD2.1.3.2 


INPUT TC-B FOR BULK ENROLLMENT 


SSD2.1.3.3 


INPUT TC-N FOR ADMINISTRATIVE 
ENROLLMENT 


SSD2. 1.3.4 


INPUT TC-R FOR RE-ENROLLMENT 


SSD2.1.3.5 


INPUT TC-S FOR SPECIAL RE-ENROLLMENT 


SSD2.1.3.6 


UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH ENROLLMENT 


SSD2.2 


PROCESS CHANGE TO STUDENT INFORMATION 


SSD2.2.1 


IDENTIFY STUDENT REQUESTING CHANGE TO 
INFORMATION 


SSD2. 2.1.1 


OBTAIN SSN OF STUDENT REQUESTING CHANGE 


SSD2.2. 1.2 


INPUT SSN OF STUDENT REQUESTING CHANGE 


SSD2.2.2 


DETERMINE INFORMATION TO CHANGE 


SSD2.2.2. 1 


PROCESS CHANGE TO STUDENT'S NAME 


SSD2.2.2.1.1 


OBTAIN CHANGE TO STUDENT'S NAME 


SSD2.2.2.1.2 


INPUT CHANGE TO STUDENT'S NAME 


SSD2.2.2.2 


PROCESS CHANGE TO STUDENTS RANK 
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Activity Number 


Activity Name 


SSD2.2. 2.2.1 


OBTAIN CHANGE TO STUDENT'S RANK 


SSD2.2.2.2.2 


INPUT CHANGE TO STUDENT'S RANK 


SSD2.2.2.3 


PROCESS CHANGE TO SERVICE COMPONENT 


SSD2.2. 2.3.1 


OBTAIN CHANGE TO STUDENT'S SERVICE 
COMPONENT 


SSD2.2.2.3.2 


INPUT CHANGE TO STUDENT'S SERVICE 
COMPONENT 


SSD2.2.2.4 


PROCESS CHANGE TO SERVICE STATUS 


SSD2.2.2.4.1 


OBTAIN CHANGE TO STUDENT'S SERVICE 
STATUS 


SSD2.2.2.4.2 


INPUT CHANGE TO STUDENT'S SERVICE 
STATUS 


SSD2.2.2.5 


PROCESS CHANGE TO STUDENT'S ADDRESS 


SSD2.2.2.5.1 


OBTAIN CHANGE TO STUDENT'S ADDRESS 


SSD2.2. 2.5.2 


INPUT CHANGE TO STUDENT'S ADDRESS 


SSD2.2.3 


ENTER TRANSACTION CODE FOR CHANGE 


SSD2.2.3.1 


INPUT TC-D FOR CHANGE TO STUDENT'S DATA 


SSD2.2.3.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
CHANGE 


SSD2.3 


PROCESS REQUEST FOR ADMINISTRATIVE 
ACTION 


SSD2.3.1 


PROCESS REQUEST FOR EXTENSION 


SSD2.3.1.1 


IDENTIFY EXTENSION STUDENT 


SSD2.3. 1.1.1 


OBTAIN SSN OF EXTENSION STUDENT 


SSD2.3. 1.1.2 


INPUT SSN OF EXTENSION STUDENT 


SSD2.3. 1.1.3 


OBTAIN NAME OF EXTENSION STUDENT 


SSD2.3. 1.1.4 


INPUT NAME OF EXTENSION STUDENT 


SSD2.3.1.2 


VERIFY INFORMATION OF EXTENSION STUDENT 


SSD2.3. 1.2.1 


VALIDATE INFORMATION OF EXTENSION 
STUDENT 


SSD2.3. 1.2.2 


INPUT MISSING INFORMATION FOR EXTENSION 
STUDENT 


SSD2.3. 1.2.3 


VALIDATE EXTENSION STUDENT MEETS 
PREREQUISITES 


SSD2.3.1.3 


DETERMINE COURSE OF EXTENSION STUDENT 


SSD2.3. 1.3.1 


OBTAIN COURSE OF EXTENSION STUDENT 


SSD2.3.1.3.2 


INPUT COURSE CODE OF EXTENSION STUDENT 


SSD2.3.1.4 


ENTER TRANSACTION CODE FOR EXTENSION 


SSD2.3.1.4.1 


INPUT TC-E FOR EXTENSION 


SSD2.3. 1.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
EXTENSION 
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Activity Number 


Activity Name 


SSD2.3.2 


PROCESS REQUEST FOR DIS ENROLLMENT 


SSD2.3.2. 1 


IDENTIFY DISENROLLMENT STUDENT 


SSD2.3.2.1.1 


OBTAIN SSN OF DISENROLLMENT STUDENT 


SSD2.3.2.1.2 


INPUT SSN OF DISENROLLMENT STUDENT 


SSD2.3.2.2 


DETERMINE COURSE OF DISENROLLMENT 
STUDENT 


SSD2.3.2.2.1 


OBTAIN COURSE OF DISENROLLMENT STUDENT 


SSD2.3.2.2.2 


INPUT COURSE OF DISENROLLMENT STUDENT 


SSD2.3.2.3 


VERIFY INFORMATION OF DISENROLLMENT 
STUDENT 


SSD2.3.2.3. 1 


VALIDATE INFORMATION ABOUT 
DISENROLLMENT CUSTOMER 


SSD2.3. 2.3.2 


INPUT MISSING INFORMATION ABOUT 
DISENROLLMENT CUSTOMER 


SSD2.3.2.3.3 


VALIDATE DISENROLLMENT CUSTOMER MEETS 
PREREQUISITES 


SSD2.3.2.4 


ENTER TRANSACTION CODE FOR 
DISENROLLMENT 


SSD2.3. 2.4.1 


INPUT TC-H FOR DISENROLLMENT 


SSD2.3.2.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
DISENROLLMENT 


SSD2.3.3 


PROCESS EXAM ISSUE 


SSD2.3.3.1 


IDENTIFY STUDENT FOR EXAM ISSUE 


SSD2.3.3.1.1 


OBTAIN SSN OF STUDENT FOR EXAM ISSUE 


SSD2.3.3.1.2 


INPUT SSN OF STUDENT FOR EXAM ISSUE 


SSD2.3.3.1.3 


OBTAIN NAME OF STUDENT FOR EXAM ISSUE 


SSD2.3.3.1.4 


INPUT NAME OF STUDENT FOR EXAM ISSUE 


SSD2.3.3.2 


IDENTIFY COURSE FOR EXAM ISSUE 


SSD2.3.3.2.1 


OBTAIN COURSE FOR EXAM ISSUE 


SSD2.3.3.2.2 


INPUT COURSE CODE FOR EXAM ISSUE 


SSD2.3.3.3 


VERIFY STUDENT INFORMATION FOR EXAM 
ISSUE 


SSD2.3.3.3.1 


VALIDATE INFORMATION OF STUDENT FOR 
EXAM ISSUE 


SSD2.3.3.3.2 


INPUT MISSING INFORMATION OF STUDENT FOR 
EXAM ISSUE 


SSD2.3.3.3.3 


VALIDATE STUDENT MEETS PREREQUISITES 
FOR EXAM ISSUE 


SSD2.3.3.4 


ENTER TRANSACTION CODE FOR EXAM ISSUE 


SSD2.3.3.4.1 


INPUT TC-I FOR EXAM ISSUE 


SSD2.3.3.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE FOR 
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Activity Name 




EXAM ISSUE 


SSD2.3.4 


PROCESS ADMIN CREDIT FOR PME 


SSD2.3.4.1 


IDENTIFY CUSTOMER FOR PME ADMIN CREDIT 


SSD2.3.4.1.1 


OBTAIN SSN OF CUSTOMER FOR PME ADMIN 
CREDIT 


SSD2.3.4.1.2 


INPUT SSN OF CUSTOMER FOR PME ADMIN 
CREDIT 


SSD2.3.4.2 


DETERMINE COURSE FOR PME ADMIN CREDIT 


SSD2.3.4.2.1 


OBTAIN COURSE FOR PME ADMIN CREDIT 


SSD2.3.4.2.2 


INPUT COURSE FOR PME ADMIN CREDIT 


SSD2.3.4.3 


VERIFY CUSTOMER INFORMATION FOR PME 
ADMIN CREDIT 


SSD2.3.4.3.1 


VALIDATE INFORMATION ABOUT CUSTOMER 
FOR PME ADMIN CREDIT 


SSD2.3.4.3.2 


INPUT MISSING INFORMATION ABOUT 
CUSTOMER FOR PME ADMIN CREDIT 


SSD2.3.4.3.3 


VALIDATE CUSTOMER FOR PME ADMIN CREDIT 
MEETS PREREQUISITES 


SSD2.3.4.4 


ENTER TRANSACTION CODE FOR ADMIN CREDIT 
FOR PME 


SSD2.3. 4.4.1 


INPUT TC-0 FOR PME ADMIN CREDIT 


SSD2.3.4.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE FOR 
PME ADMIN CREDIT 


SSD2.4 


PROCESS STANDARD REQUEST FOR MATERIAL 


SSD2.4.1 


IDENTIFY STUDENT REQUESTING MATERIAL 


SSD2.4.1.1 


OBTAIN SSN OF STUDENT REQUESTING 
STANDARD MATERIAL 


SSD2.4.1.2 


INPUT SSN OF STUDENT REQUESTING 
STANDARD MATERIAL 


SSD2.4.2 


DETERMINE STANDARD MATERIAL REQUESTED 


SSD2. 4.2.1 


DETERMINE LESSON FOR LESSON ANSWER 
SHEET ISSUE 


SSD2.4.2.2 


DETERMINE COURSE FOR DUPLICATE DIPLOMA/ 
COMPLETION CERTIFICATE ISSUE 


SSD2.4.2.3 


DETERMINE COURSE FOR INDIVIDUAL DP-37 
ISSUE 


SSD2.4.2.4 


DETERMINE COURSE OF DUPLICATE COURSE 
MATERIAL ISSUE 


SSD2.4.3 


INPUT TRANSACTION CODE FOR STANDARD 
MATERIAL ISSUE 


SSD2.4.3.1 


INPUT TC-L FOR LESSON ANSWER SHEET ISSUE 


SSD2.4.3.2 


INPUT TC-P FOR DUPLICATE COURSE 



Table B-2. As-Is Process Model Decomposition Diagram. 

192 



Activity Number 


Activity Name 




MATERIALS ISSUE 


SSD2.4.3.3 


INPUT TC-T FOR INDIVIDUAL DP-37 ISSUE 


SSD2.4.3.4 


INPUT TC-Y FOR DUPLICATE DIPLOMA/ 
COMPLETION CERTIFICATE ISSUE 


SSD2.4.3.5 


UPDATE ON-LINE TRANSACTION R-6 FILE FOR 
STANDARD MATERIAL ISSUE 


SSD3 


GRADE STUDENTS' EXAMS 


SSD3.1 


PROCESS PRE-SLUGGED DP-37s 


SSD3.1.1 


RUN PRE-SLUGGED DP-37s THROUGH 
SCANTRON 


SSD3. 1.1.1 


LOAD PRE-SLUGGED DP-37s INTO SCANTRON 


SSD3. 1.1.2 


CREATE DISK WITH SCORES FOR GRADED PRE- 
SLUGGED DP-37s 


SSD3.1.2 


FILE SCANNED PRE-SLUGGED DP-37s 


SSD3.1.3 


FORWARD UNSCANNED PRE-SLUGGED DP-37s 
TO BE HAND GRADED 


SSD3.2 


PROCESS GENERIC DP-37 s 


SSD3.2.1 


SCREEN GENERIC DP-37s 


SSD3.2.2 


RUN GENERIC DP-37s THROUGH SCANTRON 


SSD3.2.2.1 


LOAD GENERIC DP-37s INTO SCANTRON 


SSD3. 2.2.2 


CREATE DISK WITH SCORES FOR GRADED 
GENERIC DP-37s 


SSD3.2.3 


FILE SCANNED GENERIC DP-37s 


SSD3.2.4 


FORWARD UNSCANNED GENERIC DP-37s TO BE 
HAND GRADED 


SSD3.3 


PROCESS OPSCAN ERROR LISTING REPORT 


SSD3.4 


PROCESS HAND GRADED EXAMS 


SSD3.4.1 


HANDGRADE NON-SCANNABLE DP-37S 


SSD3.4.2 


ENTER SCORES FOR HAND GRADED EXAMS 


SSD3.4.3 


ENTER SCORES FOR PME EXAMS 


SSD4 


PROCESS UNIT ACTIVITY REPORTS 


SSD4.1 


WORK RETURNED UARs 


SSD4.1.1 


MAKE DESIRED UPDATES FROM UAR 


SSD4.1.1.1 


PROCESS UAR REQUEST FOR ENROLLMENT 


SSD4.1. 1.1.1 


IDENTIFY UAR ENROLLMENT CUSTOMER 


SSD4.1.1. 1.1.1 


OBTAIN SSN OF UAR ENROLLMENT CUSTOMER 


SSD4.1.1. 1.1.2 


INPUT SSN OF UAR ENROLLMENT CUSTOMER 


SSD4.1. 1.1.2 


DETERMINE DESIRED COURSE OF UAR 
ENROLLMENT CUSTOMER 


SSD4.1.1. 1.2.1 


OBTAIN DESIRED COURSE NUMBER OF UAR 
ENROLLMENT CUSTOMER 
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Activity Name 


SSD4. 1.1. 1.2.2 


INPUT DESIRED COURSE NUMBER OF UAR 
ENROLLMENT CUSTOMER 


SSD4.1. 1.1.3 


VERIFY UAR ENROLLMENT CUSTOMER 
INFORMATION 


SSD4.1.1. 1.3.1 


VALIDATE UAR ENROLLMENT CUSTOMER 
INFORMATION 


SSD4.1.1. 1.3.2 


INPUT MISSING UAR ENROLLMENT CUSTOMER 
INFORMATION 


SSD4.1.1. 1.3.3 


VALIDATE UAR ENROLLMENT CUSTOMER 
MEETS COURSE PRE-REQUISITES 


SSD4.1. 1.1.4 


ENTER TRANSACTION CODE FOR UAR 
ENROLLMENT 


SSD4.1.1. 1.4.1 


INPUT TC-A FOR UAR ENROLLMENT 


SSD4.1.1. 1.4.2 


UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH UAR ENROLLMENT 


SSD4.1.1.2 


PROCESS UAR REQUEST FOR DATA CHANGE 


SSD4.1. 1.2.1 


IDENTIFY UAR CUSTOMER FOR DATA CHANGE 


SSD4.1. 1.2.1. 1 


OBTAIN SSN OF UAR CHANGE CUSTOMER 


SSD4.1.1.2.1.2 


INPUT SSN OF UAR CHANGE CUSTOMER 


SSD4.1. 1.2.2 


DETERMINE INFORMATION TO CHANGE BY UAR 


SSD4.1. 1.2.2. 1 


PROCESS UAR CHANGE TO STUDENT'S NAME 


SSD4.1.1.2.2.1.1 


OBTAIN UAR CHANGE TO STUDENT’S NAME 


SSD4.1.1.2.2.1.2 


INPUT CHANGE TO STUDENT’S NAME BY UAR 


SSD4.1.1.2.2.2 


PROCESS UAR CHANGE TO STUDENT'S 
ADDRESS 


SSD4.1.1.2.2.2.1 


OBTAIN UAR CHANGE TO STUDENT'S ADDRESS 


SSD4.1.1.2.2.2.2 


INPUT UAR CHANGE TO STUDENT'S ADDRESS 


SSD4.1.1.2.2.3 


PROCESS UAR CHANGE TO STUDENT'S RANK 


SSD4.1.1.2.2.3.1 


OBTAIN UAR CHANGE TO STUDENT'S RANK 


SSD4. 1.1.2.2.3.2 


INPUT UAR CHANGE TO STUDENT'S RANK 


SSD4.1. 1.2.3 


ENTER TRANSACTION CODE FOR UAR CHANGE 


SSD4.1. 1.2.3. 1 


ENTER TC-D FOR DATA CHANGE BY UAR 


SSD4.1.1.2.3.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
UAR CHANGE 


SSD4. 1.1.3 


PROCESS UAR REQUEST FOR EXTENTION 


SSD4.1. 1.3.1 


IDENTIFY UAR EXTENTION CUSTOMER 


SSD4.1.1.3.1.1 


OBTAIN SSN OF UAR EXTENTION CUSTOMER 


SSD4.1.1.3.1.2 


INPUT SSN OF UAR EXTENTION CUSTOMER 


SSD4.1. 1.3.2 


DETERMINE DESIRED COURSE OF UAR 
EXTENTION CUSTOMER 


SSD4.1. 1.3.2. 1 


OBTAIN DESIRED COURSE NUMBER OF UAR 
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Activity Name 




EXTENTION CUSTOMER 


SSD4. 1.1. 3.2.2 


INPUT DESIRED COURSE NUMBER OF UAR 
EXTENTION CUSTOMER 


SSD4.1. 1.3.3 


VERIFY UAR EXTENTION CUSTOMER 
INFORMATION 


SSD4.1.1.3.3.1 


VALIDATE UAR EXTENTION CUSTOMER 
INFORMATION 


SSD4. 1.1. 3.3.2 


INPUT MISSING UAR EXTENTION CUSTOMER 
INFORMATION 


SSD4.1.1.3.3.3 


VALIDATE UAR EXTENTION CUSTOMER MEETS 
COURSE PRE-REQUISITES 


SSD4.1. 1.3.4 


ENTER TRANSACTION CODE FOR UAR 
EXTENTION CUSTOMER 


SSD4.1.1. 3.4.1 


INPUT TC-E FOR UAR EXTENTION 


SSD4.1. 1.3.42 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
UAR EXTENTION 


SSD4.1.1.4 


PROCESS UAR REQUEST FOR DISENROLLMENT 


SSD4.1. 1.4.1 


IDENTIFY UAR DISENROLLMENT CUSTOMER 


SSD4.1. 1.4.1. 1 


OBTAIN SSN OF UAR DISENROLLMENT 
CUSTOMER 


SSD4.1.1.4.1.2 


INPUT SSN OF UAR DISENROLLMENT 
CUSTOMER 


SSD4.1. 1.4.2 


DETERMINE DESIRED COURSE OF UAR 
DISENROLLMENT CUSTOMER 


SSD4.1. 1.4.2. 1 


OBTAIN DESIRED COURSE NUMBER OF UAR 
DISENROLLMENT CUSTOMER 


SSD4.1.1.4.2.2 


INPUT DESIRED COURSE NUMBER OF UAR 
DISENROLLMENT CUSTOMER 


SSD4.1. 1.4.3 


VERIFY UAR DISENROLLMENT CUSTOMER 
INFORMATION 


SSD4. 1.1. 4.3.1 


VALIDATE UAR DISENROLLMENT CUSTOMER 
INFORMATION 


SSD4. 1.1. 4.3.2 


INPUT MISSING UAR DISENROLLMENT 
CUSTOMER INFORMATION 


SSD4.1.1.4.3.3 


VALIDATE UAR DISENROLLMENT CUSTOMER 
MEETS PREREQUISITES 


SSD4.1.1.4.4 


ENTER TRANSACTION CODE FOR UAR 
DISENROLLMENT 


SSD4.1.1.4.4.1 


INPUT TC-H FOR UAR DISENROLLMENT 


SSD4. 1.1. 4.4.2 


UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
UAR DISENROLLMENT 


SSD4.1.1.5 


PROCESS UAR REQUEST FOR DUPLICATE 
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Activity Number 


^Activiti^ame_ 

MATERIALS 


SSD4.1. 1.5.1 


IDENTIFY UAR DUPLICATE MATERIALS 
CUSTOMER 


SSD4.1.1.5.1.1 


OBTAIN SSN OF UAR DUPLICATE MATERIALS 
CUSTOMER 


SSD4.1.1.5.1.2 


INPUT SSN OF UAR DUPLICATE MATERIALS 
CUSTOMER 


SSD4.1. 1.5.2 


DETERMINE DESIRED MATERIALS FOR UAR 
DUPLICATE MATERIALS CUSTOMER 


SSD4.1.1.5.2 1 


OBTAIN DESIRED MATERIALS FOR UAR 
DUPLICATE MATERIALS CUSTOMER 


SSD4.1.1.5.2.2 


DETERMINE AVAILABILITY OF DESIRED 
MATERIALS FOR UAR DUPLICATE MATERIALS 
CUSTOMER 


SSD4.1. 1.5.3 


VERIFY UAR DUPLICATE MATERIALS 
CUSTOMER INFORMATION 


SSD4.1.1.5.3.1 


VALIDATE UAR DUPLICATE MATERIALS 
CUSTOMER INFORMATION 


SSD4.1.1.5.3.2 


INPUT MISSING UAR DUPLICATE MATERIALS 
CUSTOMER INFORMATION 


SSD4.1.1.5.3.3 


VALIDATE UAR DUPLICATE MATERIALS 
CUSTOMER MEETS PRE-REQUISITES 


SSD4.1. 1.5.4 


ENTER TRANSACTION CODE FOR UAR 
DUPLICATE MATERIALS CUSTOMER 


SSD4.1.1.5.4.1 


INPUT TC-I FOR DUPLICATE EXAM BY UAR 
CUSTOMER 


SSD4.1.1.5.4.2 


INPUT TC-P FOR DUPLICATE COURSE/ 
PROGRAM BY UAR CUSTOMER 


SSD4.1.1.5.4.3 


INPUT TC-T FOR REPLACEMENT DP-37 BY UAR 
CUSTOMER 


SSD4.1.1.5.4.4 


INPUT TC-Y FOR DUPLICATE DIPLOMA/ 
COMPLETION CERTIFICATE BY UAR CUSTOMER 


SSD4.1.1.5.4.5 


UPDATE ON-LINE TRANSACTION BATCH FILE 
WITH UAR DUPLICATE MATERIALS ORDER 


SSD4.1.1.6 


PROCESS UAR REQUEST FOR RE-ENROLLMENT 


SSD4.1. 1.6.1 


IDENTIFY UAR RE-ENROLLMENT CUSTOMER 


SSD4.1. 1.6.1. 1 


OBTAIN SSN OF UAR RE-ENROLLMENT 
CUSTOMER 


SSD4. 1.1.6. 1.2 


INPUT SSN OF UAR RE-ENROLLMENT 
CUSTOMER 


SSD4.1. 1.6.2 


DETERMINE DESIRED COURSE OF UAR RE- 
ENROLLMENT CUSTOMER 
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Activity Number 


Activity Name 


SSD4.1.1.6.2.1 


OBTAIN DESIRED COURSE OF UAR RE- 
ENROLLMENT CUSTOMER 


SSD4.1.1.6.2.2 


INPUT DESIRED COURSE OF UAR RE- 
ENROLLMENT CUSTOMER 


SSD4.1. 1.6.3 


VERIFY UAR RE-ENROLLMENT CUSTOMER 
INFORMATION 


SSD4.1. 1.6.3. 1 


VALIDATE UAR RE-ENROLLMENT CUSTOMER 
INFORMATION 


SSD4.1.1.6.3.2 


INPUT MISSING UAR RE-ENROLLMENT 
CUSTOMER INFORMATION 


SSD4.1.1.6.3.3 


VALIDATE UAR RE-ENROLLMENT CUSTOMER 
MEETS PREREQUISITES 


SSD4.1. 1.6.4 


ENTER TRANSACTION CODE FOR UAR RE- 
ENROLLMENT 


SSD4.1.1.6.4.1 


INPUT TC-R FOR UAR RE-ENROLLMENT 


SSD4.1.1.6.4.2 


UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH UAR RE-ENROLLMENT 


SSD4.1.2 


PREPARE MATERIAL REQUEST FORMS FROM 
UAR 


SSD4.1.2.1 


PREPARE "REQUEST FOR MATERIAL" FORMS 
FROM UAR 


SSD4.1. 2.1.1 


WRITE STUDENT'S NAME ON "REQUEST FOR 
MATERIAL" FORMS FROM UAR 


SSD4.1.2.1.2 


WRITE STUDENT'S SSN ON "REQUEST FOR 
MATERIAL" FORMS FROM UAR 


SSD4.1.2.1.3 


WRITE STUDENT'S ADDRESS ON "REQUEST FOR 
MATERIAL" FORMS FROM UAR 


SSD4.1. 2.1.4 


WRITE DATE ON "REQUEST FOR MATERIAL" 
FORMS FROM UAR 


SSD4.1.2.1.5 


WRITE UAR CLERK'S NAME "REQUEST FOR 
MATERIAL" FORMS FROM UAR 


SSD4.1.2.1.6 


WRITE ITEM NAME ON "REQUEST FOR 
MATERIAL" FORMS FROM UAR 


SSD4.1. 2.1.7 


WRITE QUANTITY ON "REQUEST FOR 
MATERIAL" FORMS FROM UAR 


SSD4. 1.2.2 


PREPARE "OFF-LINE REQUEST" FORMS FROM 
UAR 


SSD4. 1.2.2. 1 


WRITE STUDENT'S NAME ON "OFF-LINE 
REQUEST" FORMS FROM UAR 


SSD4.1.2.2.2 


WRITE STUDENT’S SSN ON "OFF-LINE REQUEST" 
FORMS FROM UAR 


SSD4.1. 2.2.3 


WRITE STUDENT'S ADDRESS ON "OFF-LINE 
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Activity Number 


Activity Name 




REQUEST" FORMS FROM UAR 


SSD4.1. 2.2.4 


WRITE DATE ON "OFF-LINE REQUEST" FORMS 
FROM UAR 


SSD4.1.2.2.5 


WRITE UAR CLERK'S NAME ON "OFF-LINE 
REQUEST" FORMS FROM UAR 


SSD4.1.2.2.6 


WRITE ITEM NAME ON "OFF-LINE REQUEST" 
FORMS FROM UAR 


SSD4.1.2.2.7 


WRITE QUANTITY ON "OFF-LINE REQUEST" 
FORMS FROM UAR 


SSD4.1.3 


FILE WORKED UAR 


SSD4.2 


PROCESS OUTGOING UARs BY U.S. MAIL 


SSD4.2.1 


OBTAIN OUTGOING PRINTED UARs 


SSD4.2.2 


PACKAGE OUTGOING UARs BY U.S. MAIL 


SSD4.2.2.1 


SEPARATE PRINTED UARs FOR MAILING 


SSD4.2.2.2 


PLACE UARs IN ENVELOPES 


SSD4.2.2.3 


FORWARD PACKAGED UARs TO LOGISTICS 


SSD5 


PROCESS REQUEST FOR MATERIAL 


SSD5.1 


SEGREGATE REQUEST FOR REGISTRAR 
ACTION 


SSD5.2 


SEGREGATE STANDARD REQUESTS FOR 
MATERIAL 


SSD5.2.1 


VALIDATE STUDENT'S REQUEST 


SSD5.2.2 


VERIFY AVAILABILITY OF REQUESTED 
MATERIAL 


SSD5.2.3 


ENTER TRANSACTION CODE FOR REQUESTED 
MATERIAL 


SSD5.2.3.1 


ENTER TC-I FOR REQUEST FOR DUPLICATE 
EXAM 


SSD5.2.3.2 


ENTER TC-P FOR REQUEST FOR DUPLICATE 
COURSE / PROGRAM 


SSD5.2.3.3 


ENTER TC-T FOR REQUEST FOR INDIVIDUAL 
GENERIC DP-37 


SSD5.2.3.4 


ENTER TC-Y TO REQUEST FOR DUPLICATE 
DIPLOMA/COMPLETION CERTIFICATE 


SSD5.3 


PROCESS "REQUEST FOR MATERIAL" FORMS 


SSD5.3.1 


VALIDATE INFORMATION ON "REQUEST FOR 
MATERIAL" FORM 


SSD5.3.1.1 


VALIDATE NAME ON "REQUEST FOR MATERIAL" 
FORM 


SSD5.3.1.2 


VALIDATE SSN ON "REQUEST FOR MATERIAL" 
FORM 


SSD5.3.1.3 


VALIDATE ADDRESS ON "REQUEST FOR 
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Activity Number 


| Activity Name 




MATERIAL” FORM 


SSD5.3.1.4 


VALIDATE QUANTITY ON "REQUEST FOR 
MATERIAL" FORM 


SSD5.3.2 


PREPARE MATERIAL REQUESTED ON "REQUEST 
FOR MATERIAL" FORM 


SSD5.3.2.1 


TYPE "REQUEST FOR MATERIAL" MAILING 
LABELS 


SSD5.3.2.2 


OBTAIN MATERIAL REQUESTED ON "REQUEST 
FOR MATERIAL" FORM 


SSD5.3.3 


PREPARE PACKAGE OF "REQUEST FOR 
MATERIAL" FORM 


SSD5.3.3.1 


PLACE "REQUEST FOR MATERIAL" MAILING 
LABELS ON ENVELOPE 


SSD5. 3.3.2 


INSERT MATERIAL REQUESTED ON "REQUEST 
FOR MATERIAL" FORM INTO ENVELOPE 


SSD5.3.3.3 


FORWARD "REQUEST FOR MATERIAL" 
PACKAGE TO LOGISTICS MAILROOM 


SSD5.4 


SEGREGATE "OFF-LINE REQUEST" FORMS 


SSD5.4.1 


COMPLETE "OFF-LINE REQUEST" FORM 


SSD5.4.2 


VALIDATE INFORMATION ON "OFF-LINE 
REQUEST" FORM 


SSD5.4.3 


FORWARD "OFF-LINE REQUEST" FORM TO 
LOGISTICS 


SSD5.4.4 


FORWARD "OFF-LINE REQUEST" FORM TO 
OPERATIONS 


SSD6 


PROCESS REQUESTS FOR REGISTRAR ACTION 


SSD6.1 


ISSUE (RE-ISSUE) DIPLOMA 


SSD6.1.1 


OBTAIN DIPLOMA MAILING LABELS 


SSD6.1.2 


PRINT DIPLOMAS 


SSD6. 1.2.1 


LOAD DIPLOMA PRINT FILE 


SSD6.1.2.2 


EXECUTE DIPLOMA PRINT PROGRAM 


SSD6.1.3 


PACKAGE DIPLOMA FOR MAILING 


SSD6. 1.3.1 


PLACE DIPLOMA MAILING LABEL ON 
ENVELOPE 


SSD6.1.3.2 


INSERT DIPLOMA INTO ENVELOPE 


SSD6.1.3.3 


FORWARD PACKAGED DIPLOMA TO LOGISTICS 
MAILROOM 


SSD6.2 


PROCESS TRANSCRIPT REQUEST 


SSD6.2.1 


OBTAIN CUSTOMER TRANSCRIPT INFORMATION 


SSD6.2.1. 1 


VERIFY TRANSCRIPT CUSTOMER'S PERSONAL 
INFORMATION 


SSD6.2. 1.1.1 


VERIFY TRANSCRIPT CUSTOMER’S NAME 
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Activity Number 


Activity Name 


SSD6.2. 1.1.2 


VERIFY TRANSCRIPT CUSTOMER'S SSN 


SSD6.2. 1.1.3 


VERIFY TRANSCRIPT CUSTOMER'S ADDRESS 


SSD6.2. 1.1.4 


VERIFY TRANSCRIPT CUSTOMER'S DATES OF 
SERVICE 


SSD6.2.1.2 


PERFORM RESEARCH FOR STUDENT COURSE 
INFORMATION 


SSD6.2.1.2.1 


SEARCH ON-LINE DATA FOR STUDENT COURSE 
INFORMATION 


SSD6.2.1.2.1.1 


SEARCH ACTIVE FILES FOR TRANSCRIPT 
INFORMATION 


SSD6.2. 1.2.1.2 


SEARCH ARCHIVE FILES FOR TRANSCRIPT 
INFORMATION 


SSD6.2.1.2.2 


SEARCH MICROFICHE DATA FOR STUDENT 
COURSE INFORMATION 


SSD6.2. 1.2.3 


REFER CUSTOMER TO HQMC FOR COURSES 
PRIOR TO JAN 79 


SSD6.2. 1.3 


OBTAIN STUDENT COURSE INFORMATION 


SSD6.2. 1.3.1 


OBTAIN STUDY HOURS 


SSD6.2. 1.3.2 


OBTAIN ENROLLMENT DATE 


SSD6.2. 1.3.3 


OBTAIN COMPLETION DATE 


SSD6.2. 1.3.4 


OBTAIN GRADE PERCENT 


SSD6.2. 1.3.5 


OBTAIN COURSE NUMBER 


SSD6.2. 1.3.6 


OBTAIN COURSE TITLE 


SSD6.2.2 


PREPARE TRANSCRIPT 


SSD6.2.2. 1 


COMPLETE TRANSCRIPT FORM ON SCREEN 


SSD6.2.2.2 


PRINT TRANSCRIPT 


SSD6.2.2.3 


PRINT TRANSCRIPT LETTER 


SSD6.2.2.4 


TYPE TRANSCRIPT MAILING LABEL 


SSD6.2.3 


PACKAGE TRANSCRIPT FOR MAILING 


SSD6.2.3. 1 


INSERT TRANSCRIPT INTO ENVELOPE 


SSD6.2.3.2 


INSERT TRANSCRIPT LETTER INTO ENVELOP 


SSD6. 2.3.3 


PLACE TRANSCRIPT MAILING LABEL ON 
TRANSCRIPT ENVELOPE 


SSD6.2.3.4 


FORWARD TRANSCRIPT PACKAGE TO LOGISTICS 
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Figure B-2. As-Is Process Model Node Tree Diagram (SSD1). 
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APPENDIX C. TO-BE PROCESS MODEL 



This appendix contains the components of the To-Be Process Model 
documentation. Table C-l is a list of tables and figures as they appear in the appendix. 



Number 


Title 


Table C-2 


To-Be Process Model Decomposition Diagram 


Table C-3 


To-Be Activity Dictionary 


Table C-4 


To-Be Arrow Dictionary 


Figure C- 1 


To-Be Process Model Node Tree Diagram (TO) 
All Levels - Student Service Support 


Figure C-2 


To-Be Process Model Context Diagram (T-0) 


Figure C-3 - C-37 


To-Be Process Model IDEFO Diagrams 


Figure C-38 


To-Be Process Model CRUD Matrix 


Figure C-39 


To-Be Process Model Clustered CR Matrix 



Table C-l. List of To-Be Process Model Components. 
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Activity Number 


Activity Name 


TO 


STUDENT SERVICING 


T1 


CUSTOMER SERVICING 


Tl.l 


OBTAIN CUSTOMER INPUT 


Tl.1.1 


PROCESS INCOMING PHONE CALLS 


Tl.1.2 


PROCESS WALK-IN CUSTOMERS 


Tl.l. 3 


SORT INCOMING U.S. MAIL 


Tl. 1.3.1 


SEGREGATE STUDENT COURSE INPUT 


Tl. 1.3.1. 1 


SEGREGATE FEEDBACK FORMS 


Tl. 1.3. 1.2 


SEGREGATE GENERIC DP-37s 


Tl.l. 3.1.3 


SEGREGATE PRE-SLUGGED DP-37s 


Tl. 1.3. 1.4 


SEGREGATE ESSAY EXAMS 


Tl. 1.3.2 


SEGREGATE MAILED INQUIRIES 


Tl. 1.3.3 


SEGREGATE UNIT INPUT 


Tl.1.4 


SORT INCOMING E-MAIL 


Tl. 1.4.1 


SEGREGATE E-MAIL STATUS REQUEST 


Tl. 1.4.2 


SEGREGATE E-MAIL STATUS CHANGES 


Tl. 1.4.3 


SEGREGATE E-MAIL MATERIAL REQUESTS 


Tl. 1.4.4 


SEGREGATE E-MAIL UAR RESPONSE 


Tl. 1.4.5 


SEGREGATE PERSONAL E-MAIL 


T1.2 


PROVIDE UNIT ACTIVITY SERVICES 


Tl.2.1 


PREPARE UARs 


Tl.2.2 


WORK RETURNED UARs 


T2 


STUDENT ACTIVITY SERVICING 


T2.1 


PROCESS ENROLLMENT 


T2.1.1 


DETERMINE TYPE OF ENROLLMENT 


T2.1.2 


VALIDATE ENROLLMENT REQUIREMENTS 


T2. 1.2.1 


EVALUATE SERVICE COMPONENT 


T2. 1.2.2 


EVALUATE GRADE 


T2. 1.2.3 


EVALUATE COURSE/PROGRAM HISTORY 


T2.2 


PROCESS STATUS REQUEST 


T2.2.1 


PROCESS COURSE STATUS REQUEST 


T2.2.1.1 


DETERMINE ENROLLMENT STATUS 


T2.2.1.2 


DETERMINE COURSE STATUS 


T2.2.1.3 


DETERMINE EXAMINATION STATUS 


T2.2.1.4 


DETERMINE CERTIFICATION STATUS 


T2.2.2 


PROCESS TRANSCRIPT STATUS REQUEST 


T2.2.2.1 


DETERMINE PROGRESS OF RESEARCH 


T2.2.2.2 


DETERMINE TRANSCRIPT SHIP DATE 


T2.2.3 


PROCESS MATERIAL STATUS REQUEST 


T2.2.3.1 


DETERMINE COURSE MATERIAL STATUS 
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Activity Number 


Activity Name 


T2.2.3.2 


DETERMINE COMPONENT SHIP STATUS 


T2.2.3.3 


DETERMINE JOB AID SHIP STATUS 


T2.2.3.4 


DETERMINE CERTIFICATION SHIP STATUS 


T2.2.3.5 


DETERMINE UNIT MATERIAL SHIP STATUS 


T2.3 


CHANGE STUDENT INFORMATION 


T2.3.1 


PROCESS NAME CHANGE 


T2.3.2 


PROCESS SSN CHANGE 


T2.3.3 


PROCESS GRADE CHANGE 


T2.3.4 


PROCESS SERVICE COMPONENT CHANGE 


T2.3.5 


PROCESS SERVICE STATUS CHANGE 


T2.3.6 


PROCESS ADDRESS CHANGE 


T2.4 


PROCESS ADMINISTRATIVE ACTION 


T2.4.1 


DETERMINE TYPE OF ADMIN ACTION 


T2.4.2 


VALIDATE ADMIN ACTION 


T2.4.2.1 


EVALUATE ENROLLMENT STATUS 


T2.4.2.2 


EVALUATE EXAM ISSUE STATUS 


T2.4.2.3 


EVALUATE COURSE HISTORY 


T2.4.2.4 


EVALUATE OTHER COURSE CREDIT 


T2.5 


PROCESS REQUEST FOR MATERIAL 


T2.5.1 


DETERMINE MATERIAL AVAILABILITY 


T2.5.2 


VALIDATE MATERIAL REQUIREMENTS 


T2.5.2.1 


EVALUATE STUDENT STATUS 


T2.5.2.2 


EVALUATE MILITARY/ DOD STATUS 


T2.5.2.3 


EVALUATE UNIT REP STATUS 


T2.5.2.4 


EVALUATE FOREIGN MILITARY STATUS 


T3 


GRADING 


T3.1 


PROCESS DP-37s 


T3.1.1 


PROCESS PRE-SLUGGED DP-37s 


T3.1.1.1 


SCAN PRE-SLUGGED DP- 37s 


T3. 1.1.2 


FILE SCANNED PRE-SLUGGED DP-37s 


T3. 1.1.3 


FORWARD UNSCANNED PS DP-37s 


T3.1.2 


PROCESS GENERIC DP-3 7s 


T3. 1.2.1 


SCAN GENERIC DP- 37s 


T3.1.2.2 


FILE SCANNED GENERIC DP-37s 


T3. 1.2.3 


FORWARD UNSCANNED GEN DP-37s 


T3.2 


PROCESS HAND GRADED EXAMS 


T3.2.1 


HAND GRADE NON-SCANNABLE DP-37s 


T3.2.2 


ENTER HAND GRADED EXAMS SCORES 


T3.2.3 


ENTER SCORES FOR PME EXAMS 


T3.3 


RUN GRADING PROGRAM 
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Activity Number 


| Activity Name 


T3.3.1 


EDIT DP-37 DATA 


T3.3.1.1 


EDIT PRE-SLUGGED DP-37 DATA 


T3.3.1.2 


EDIT GENERIC DP-37 DATA 


T3.3.2 


ANALYZE DP-37 DATA 


T3.3.2.1 


EVALUATE EXAM 


T3.3.2.2 


COMPARE STUDENT RECORD HISTORY 


T3.4 


PROCESS OPSCAN ERRORS 


T3.4.1 


PRODUCE OPSCAN ERROR REPORT 


T3.4.2 


CORRECT ERRONEOUS DP-37 


T3.4.3 


FIND ERRONEOUS DP-37 


T4 


REGISTRAR SERVICING 


T4.1 


ISSUE DIPLOMA 


T4.1.1 


PRINT DIPLOMAS 


T4.1.2 


PACKAGE DIPLOMA FOR MAILING 


T4.2 


ISSUE TRANSCRIPT 


T4.2.1 


VERIFY REQUESTOR INFORMATION 


T4.2.1.1 


INPUT REQUESTOR'S SSN 


T4.2.1.2 


INPUT REQUESTOR’S NAME 


T4.2.1.3 


INPUT REQUESTOR'S ADDRESS 


T4.2.1.4 


INPUT REQUESTOR’S DATES OF SERVICE 


T4.2.2 


RESEARCH TRANSCRIPT INFORMATION 


T4.2.2.1 


SEARCH ON-LINE DATA 


T4.2.2.1.1 


SEARCH ACTIVE FILES 


T4.2.2.1.2 


SEARCH ARCHIVE FILES 


T4.2.2.2 


SEARCH MICROFICHE 


T4.2.2.2. 1 


INPUT COURSE NUMBER 


T4.2.2.2.2 


INPUT COURSE TITLE 


T4.2.2.2.3 


INPUT COMPLETION DATE 


T4.2.2.2.4 


INPUT ENROLLMENT DATE 


T4.2.2.2.5 


INPUT GRADE PERCENT 


T4.2.2.2.6 


INPUT STUDY HOURS 


T4.2.2.3 


REFER CUSTOMER TO HQMC 


T4.2.3 


PRINT TRANSCRIPT 


T4.2.4 


PACKAGE TRANSCRIPT FOR MAILING 
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Activity Name 


Activity Definition 


ANALYZE DP-37 DATA 


This activity represents the process of 
retrieving the DP-37 data and grading it to 
determine if the examination passed. 


CHANGE STUDENT INFORMATION 


This activity represents the processes that 
enable the MCI clerk to change student 
information. Information that can be 
changed includes name, rank, SSN, address, 
service status and service component. 


COMPARE STUDENT RECORD 
HISTORY 


If the student passes the exam, the student 
course record is updated on the database to 
reflect a completed course. If the completed 
course is a PME course, the students 
records are read to see if the student has 
completed all of the sub-courses for that 
PME. If all of the sub-courses are complete, 
the PME record is updated to reflect a 
completed Program. The record is moved 
to the history file and a completion 
certificate and diploma will be generated. 


CORRECT ERRONEOUS DP-37 


This activity represents the process of 
correcting the file containing all the errors 
generated when editing and grading the DP- 
375. This should be done on-screen with 
direct access to student and course 
information. 


CUSTOMER SERVICING 


This business function represents the 
processes required to provide direct support 
to customers by receiving the input, 
distributing it for processing, and 
responding to the customer, when 
applicable. 


DETERMINE CERTIFICATION SHIP 
STATUS 


This activity identifies the shipping status of 
specified material in response to a request 
for completion certificate shipping status. 


DETERMINE CERTIFICATION 
STATUS 


Given the requestor is enrolled in a course 
or program, this activity determines if a 
completion certificate has been generated 
and issued to the student. The status of the 
student’s completion certification is 
returned, i.e. issue date and mailed date 
when capable. 
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Activity Name 


Activity Definition 


DETERMINE COMPONENT SHIP 
STATUS 


This activity identifies the shipping status of 
specified material in response to a request 
for component materials shipping status. 


DETERMINE COURSE MATERIAL 
STATUS 


This activity identifies the shipping status of 
specified material in response to a request 
for course or program materials status. 


DETERMINE COURSE STATUS 


Given the requestor is enrolled in a course 
or program, this activity determines the 
status of the student's progress in that 
course or program, i.e. the number of 
lessons completed (if required to be 
submitted). 


DETERMINE ENROLLMENT STATUS 


This activity determines if the requestor is 
enrolled in the course identified and 
determines the status of that enrollment. 


DETERMINE EXAMINATION STATUS 


Given the requestor is enrolled in a course 
or program, this activity determines if the 
exam has been issued, graded, or being 
processed from the Error Listing. The 
status of the student's progress or status on 
the exam is produced. 


DETERMINE JOB AID SHIP STATUS 


This activity identifies the shipping status of 
specified material in response to a request 
for job aid materials shipping status. 


DETERMINE MATERIAL 
AVAILABILITY 


This activity identifies the on hand 
availability of material for delivery given the 
type of material requested. 


DETERMINE PROGRESS OF 
RESEARCH 


This activity provides the status of progress 
researching information for a requestor's 
transcript. 


DETERMINE TRANSCRIPT SHIP DATE 


This activity provides the shipping status of 
a produced transcript in response to a 
transcript request. 


DETERMINE TYPE OF ADMIN 
ACTION 


This activity distinguishes what type of 
administrative action is requested, i.e. 
disenrollment or administrative credit for 
PME. 
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Activity Name 


Activity Definition 


DETERMINE TYPE OF ENROLLMENT 


This activity represents the process of 
determining the type of enrollment which 
applies to the requestor for the specific 
enrollment. An enrollment can be either 
regular or administrative. An administrative 
enrollment will not issue materials but 
registers the requestor into the database as 
a student. 


DETERMINE UNIT MATERIAL SHIP 
STATUS 


This activity identifies the shipping status of 
specified material in response to a request 
for unit materials shipping status. 


EDIT DP-37 DATA 


This activity represents the processes for 
loading and editing the DP-37 data. 


EDIT GENERIC DP-37 DATA 


This activity represents the process of 
editing the file with data from the generic 
DP-37s. It will convert any numeric data 
from answers to alpha-numeric data and 
ensure the required data was scanned 
properly. It will also draw student and 
course information from the MCIAIS 
database. This is where proctoring rules for 
courses 3520 and 3521 are enforced. All 
good records build a file to be graded. All 
failed records build a file for the Error 
Listing. 


EDIT PRE-SLUGGED DP-37 DATA 


This activity represents the process of 
editing the file with data from the pre- 
slugged DP-37s. It will convert any numeric 
data from answers to alpha-numeric data 
and ensure the required data was scanned 
properly. All good records build a file to be 
graded. All failed records build a file for the 
Error Listing. 


ENTER HAND GRADED EXAMS 
SCORES 


This activity represents the process of 
entering the scores from hand graded exams 
into a file for evaluation. 


ENTER SCORES FOR PME EXAMS 


This activity represents the process of 
entering the scores from PME exams into a 
file for evaluation. 
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Activity Name 


Activity Definition 


EVALUATE COURSE HISTORY 


This activity evaluates the student's course 
history to determine if previous MCI 
products completed are sufficient to 
provide the requested PME administrative 
credit. For example, if the student had been 
enrolled and completed several courses in a 
previous version of the Command and Staff 
Program, the student may be eligible for 
credit in part of the current Command and 
Staff Program. 


EVALUATE COURSE/PROGRAM 
HISTORY 


Process used to determine if the customer 
meets Course or Program pre-requisites 
based on prior completion of other MCI 
course, MCI Programs, or Resident 
Programs attended. 


EVALUATE ENROLLMENT STATUS 


This activity evaluates the enrollment status 
of the student to determine if student can be 
disenrolled or to provide credit to a course 
the student is enrolled in. 


EVALUATE EXAM 


This activity determines the student’s exam 
score and whether that score was sufficient 
to pass the course. 


EVALUATE EXAM ISSUE STATUS 


This activity evaluates if the student’s 
record contains an examination which has 
been received and graded. Administrative 
credit would not be necessary if the student 
had completed the course. A course 
completion would be issued instead of 
disenrollment if the student passed the 
exam. 


EVALUATE FOREIGN MILITARY 
STATUS 


This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials 
based on the status as a member of a 
foreign military service. 


EVALUATE GRADE 


Process used to determine if the requestor 
meets Course or Program pre-requisites 
based on grade. 


EVALUATE MILITARY/ DOD STATUS 


This activity represents the processes 
required to validate the requestor’s 
eligibility to be issued requested materials 
based on the status as a military or DoD 
employee. 
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Activity Name 


Activity Definition 


EVALUATE OTHER COURSE CREDIT 


This activity evaluates course work 
completed from other similar non-MCI 
courses or programs like might provide 
similar areas of study credit, i.e. War 
College, Armed Forces Staff College, etc. 


EVALUATE SERVICE COMPONENT 


Process used to determine if the requestor 
meets Course or Program pre-requisites 
based on service component. 


EVALUATE STUDENT STATUS 


This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials 
based on the status as a student. 


EVALUATE UNIT REP STATUS 


This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials 
based on the status as a unit training 
representative. 


FILE SCANNED GENERIC DP-37s 


This activity represents the manual process 
of filing the scanned DP- 37s into a file after 
successful scanning until the OpScan Error 
Listing is processed. 


FILE SCANNED PRE-SLUGGED DP-37s 


This activity represents the manual process 
of filing the scanned DP- 37s into a file after 
successful scanning until the OpScan Error 
Listing is processed. 


FIND ERRONEOUS DP-37 


This activity represents the process of 
correcting the file containing all the 
remaining errors, after on-line processing, 
generated when editing and grading the DP- 
378. This requires viewing the original DP- 
37 submitted. 


FORWARD UNSCANNED GEN DP-37s 


This activity represents the manual process 
of forwarding the unscannable DP-37s to 
the grading section for hand-grading. 


FORWARD UNSCANNED PS DP-37s 


This activity represents the manual process 
of forwarding the unscannable DP-37s to 
the grading section for hand-grading. 


GRADING 


This business function represents the 
processes required to grade and record 
student examinations in the database. 
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Activity Name 


Activity Definition 


HAND GRADE NON-SCANNABLE DP- 
378 


Process of hand grading DP-37s either 
rejected by the Scantron or received as 
unscannable (photo copy or mutilated). 
Involves locating course number and exam 
version number in binder and extracting key 
for hand grading exam, then manually 
checking for passing score and entering 
pass/fail information in MCLAIS. 


INPUT COMPLETION DATE 


Enter the requestor's Course completion 
date from research. 


INPUT COURSE NUMBER 


Enter the requestor's Course number from 
research. 


INPUT COURSE TITLE 


Enter the requestor's Course title from 
research. 


INPUT ENROLLMENT DATE 


Enter the requestor's Course enrollment 
date from research. 


INPUT GRADE PERCENT 


Enter the requestor's grade received for 
completing Course from research. 


INPUT REQUESTOR’S ADDRESS 


Enter the requestor's address. 


INPUT REQUESTOR'S DATES OF 
SERVICE 


Enter the requestor's dates of service. 


INPUT REQUESTOR'S NAME 


Enter the requestor's name. 


INPUT REQUESTOR'S SSN 


Enter the requestor's SSN. 


INPUT STUDY HOURS 


Enter the requestor's number of study hours 
for completing Course from research. 


ISSUE DIPLOMA 


This activity represents the processes 
required to produce and issue diplomas to 
student's completing the required Courses 
for MCI Programs. This activity also 
applies to requests for duplicate diplomas. 


ISSUE TRANSCRIPT 


This activity represents the process of 
preparing a transcript and the form letter 
reply in response to a transcript request. 


OBTAIN CUSTOMER INPUT 


This activity represents the processes of 
receiving input from customers and the 
subsequent distribution of the input for 
processing. Input can be received by phone, 
walk-in, U.S. Mail, or electronic mail (also 
considered as naval message). 


PACKAGE DIPLOMA FOR MAILING 


This activity represents the process of 
packaging the diploma into an envelope for 
mailing. 
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Activity Name 


Activity Definition 


PACKAGE TRANSCRIPT FOR 
MAILING 


This activity represents the processes 
required to package and deliver a student's 
transcript in response to a transcript 
request. 


PREPARE UARs 


This activity represents the generation of a 
Unit Activity Report used to reconcile 
student activity with a Marine Corp Unit 
and the unit commander with unit MCI 
participation summary information. 


PRINT DIPLOMAS 


This activity represents the process of 
printing diplomas to be issued or re-issued. 


PRINT TRANSCRIFT 


This activity represents the process of 
preparing a transcript and the form letter 
reply in response to a transcript request. 


PROCESS GENERIC DP-37s 


This activity represents the processes 
required to build input files with data from 
the student exams that have not been pre- 
slugged with student and course 
information for evaluation. 


PROCESS ADDRESS CHANGE 


This activity represents the process of 
changing a student's address. 


PROCESS ADMINISTRATIVE ACTION 


This activity represents the processes of 
completing administrative actions such as, 
disenrollment and administrative credit for 
Professional Military Education Courses. 


PROCESS COURSE STATUS REQUEST 


This activity represents the processes 
required to provide a student the status on 
the courses and/or programs in which 
currently enrolled. 


PROCESS DP-37s 


This activity represents the processes 
required to build files with data from the 
student exams (DP-37) for evaluation. 
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Activity Name 


Activity Definition 


PROCESS ENROLLMENT 


This activity refers to the enrollment of a 
requestor into an MCI Course or MCI 
Program. The processes require identifying 
the requestor, the requested 
course/program, and determining eligibility 
for enrollment based on course/program 
pre-requisites. Once enrolled, a requestor is 
considered a Student. There are two types 
of enrollments; Regular and Administrative. 
The enrollment action generates the 
necessary flags to initiate delivery of course 
or program materials. 


PROCESS GRADE CHANGE 


This activity represents the process of 
changing a student's rank. 


PROCESS HAND GRADED EXAMS 


This activity represents the process of 
manually hand grading examinations (DP- 
37s) which could not be scanned, entering 
the scores for those exams, and entering the 
scores for PME examinations/essays. 


PROCESS INCOMING PHONE CALLS 


This activity represents the processing of 
incoming phone calls by an MCI Immediate 
Assist Clerk. This includes such activities as 
processing an enrollment, providing status 
and general information about MCI 
Products (Job Aids, Courses and 
Programs), changing student information, 
administrative action (disenrollment and 
PME credit), and issuing material in 
response to a request. 


PROCESS MATERIAL STATUS 
REQUEST 


This activity identifies the shipping status of 
specified material in response to a shipping 
status request for component, job aid, 
course, program, or unit material. 


PROCESS NAME CHANGE 


This activity represents the process of 
changing a student's name. 


PROCESS OPS CAN ERRORS 


This activity represents the processes 
performed to generate the Opscan Error 
Report file and correcting the errors on the 
file, both on-screen and using the original 
DP-37 if necessary. 
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Activity Name 


Activity Definition 


PROCESS PRE-SLUGGED DP-37s 


This activity represents the processes 
required to build files with data from the 
student exams that have been pre-slugged 
with student and course information for 
evaluation. 


PROCESS REQUEST FOR MATERIAL 


This activity represents the processes for 
filling customer requests for material such 
as, courses, programs, components of 
courses or programs, job aids and Training 
NCO material. 


PROCESS SERVICE COMPONENT 
CHANGE 


This activity represents the process of 
changing a student's service component. 


PROCESS SERVICE STATUS CHANGE 


This activity represents the process of 
changing a student’s service status. 


PROCESS SSN CHANGE 


This activity represents the process of 
changing a student's SSN. 


PROCESS STATUS REQUEST 


This activity represents the processes 
performed to provide student's with status 
for their requests. Information is provided 
on a student's status within a Course or 
Program, status on transcript preparation, 
and status on material requests. 


PROCESS TRANSCRIPT STATUS 
REQUEST 


This activity provides the status of progress 
researching information for a requestor's 
transcript and the shipping status of a 
produced transcript in response to a 
transcript request. 


PROCESS WALK-IN CUSTOMERS 


This activity represents the processing of a 
walk-in customer by an MCI Immediate 
Assist Clerk. This includes such activities as 
processing an enrollment, providing status 
and general information about MCI 
Products (lob Aids, Courses and 
Programs), changing student information, 
administrative action (disenrollment and 
PME credit), and issuing material in 
response to a request. 


PRODUCE OPS CAN ERROR REPORT 


This activity represents the activities 
required to generate the file containing all 
the errors generated when editing and 
grading the DP-37s. 
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Activity Name 


Activity Definition 


PROVIDE UNIT ACTIVITY SERVICES 


This activity represents the processes of 
receiving input from Unit Activity 
customers (Training NCOs) and the 
subsequent processes to facilitate 
reconciliation with the Unit as a customer. 
Input can be received by phone, walk-in, 
U.S. Mail, or electronic mail (also 
considered as naval message). 
Reconciliation is initiated with a periodic 
Unit Activity Report. 


REFER CUSTOMER TO HQMC 


This activity represents the referral of 
transcript customer to HQMC for transcript 
information prior to Jan 1979. 


REGISTRAR SERVICING 


This business function represents the 
processes required to issue diplomas and 
research, produce and deliver transcripts. 


RESEARCH TRANSCRIPT 
INFORMATION 


This activity represents the processes 
performed to research and input 
information required to produce a 
transcript. 


RUN GRADING PROGRAM 


This activity represents the process of 
grading the input files containing the 
scanned data from the student 
examinations. 


SCAN GENERIC DP-37s 


This activity represents the processes of 
loading the OpScanner with Generic DP- 
378 to get the student's exam data and 
format that data into a file for the grading 
program. 


SCAN PRE-SLUGGED DP-37s 


This activity represents the processes of 
loading the OpScanner with Pre-Slugged 
DP-37s to get the student's exam data and 
format that data into a file for the grading 
program. 


SEARCH ACTIVE FILES 


This activity represents the process of 
searching the active records of MCIAIS for 
transcript customer's course completion 
history. 


SEARCH ARCHIVE FILES 


This activity represents the process of 
searching the archived records of MCIAIS 
for transcript customer's course completion 
history. 
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Activity Name 


Activity Definition 


SEARCH MICROFICHE 


This activity searches archive records on 
microfiche for transcript customer’s course 
completion history. 


SEARCH ON-LINE DATA 


This activity searches MCLAIS active and 
archive records for transcript customer's 
course completion history. 


SEGREGATE E-MAIL MATERIAL 
REQUESTS 


This activity represents the redistribution of 
electronic mail requesting material to the 
Processing Section mail-box for material 
requests. 


SEGREGATE E-MAIL STATUS 
CHANGES 


This activity represents the redistribution of 
electronic mail requesting a change to a 
requestor's status to the Processing Section 
mail-box for status change requests. 
Changing status includes enrolling, 
changing personal information, disenrolling, 
or completion of a course or part of a 
program with administrative credit. 


SEGREGATE E-MAIL STATUS 
REQUEST 


This activity represents the redistribution of 
electronic mail requesting status to the 
Processing Section mail-box for status 
requests. 


SEGREGATE E-MAIL UAR RESPONSE 


This activity represents the redistribution of 
electronic mail Unit Activity Reports to the 
Unit Activity Report Section mail-box. 


SEGREGATE ESSAY EXAMS 


This activity represents the process of 
separating PME essay exams and forwards 
them to PMED for grading. 


SEGREGATE FEEDBACK FORMS 


The process removes PMED and OSD feed 
back forms from the student course input 
received and forwards them to PMED or 
OSD for processing. 


SEGREGATE GENERIC DP-37 s 


This manual process segregates exams and 
lessons which have not been pre-formatted 
with user information for the specific course 
or program (generic DP-37 s) and forwards 
them to be graded. 
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Activity Name 


Activity Definition 


SEGREGATE MAILED INQUIRIES 


This process receives Mailed Customer 
Inquiries and forwards the Input to 
subsequent activities for processing. The 
Mailed Customer Inquiries consist of 
requests for enrollment, requests for 
missing course materials, missing 
diplomas/completion certificates, requests 
for transcripts, requests for disenrollment, 
requests for status of student progress, 
requests for course catalogs, requests for 
information about courses in general, 
change address information on individual, 
from either a student or a unit 
representative. The requests for Transcripts 
are forwarded to the Registrar Section; the 
requests for Completion Certificates, 
Diplomas, replacement materials, 
enrollment, disenrollment, and changes to 
information are forwarded to the Processing 
Section. 


SEGREGATE PERSONAL E-MAIL 


This activity represents the redistribution of 
electronic mail to a specific individual's 
mail-box for processing. 


SEGREGATE PRE-SLUGGED DP-37s 


This manual process segregates exams and 
lessons which have been pre-formatted with 
user information peculiar to the specific 
course or program (Pre-Slugged DP-37s) 
and forwards them to be graded. 


SEGREGATE STUDENT COURSE 
INPUT 


This activity processes Student Course 
Input and forwarded to subsequent 
activities. The Student Course Input should 
include a completed lesson or course 
examination (DP-37), or a copy of a 
completed DP-37, and a feedback sheet. 
The feedback sheet is forwarded to either 
PMED or OSD according to the 
course/lesson completed. The DP-37s are 
segregated by type (Generic or Pre- 
Slugged) and forwarded to the grading 
section. 
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Activity Name 


Activity Definition 


SEGREGATE UNIT INPUT 


This activity represents the process of 
receiving Unit Input and forwarding the 
Input to the UAR section for processing. 
The Unit Input should include a Unit 
Activity Report (UAR) or request for Unit 
support material. UAR input includes 
requests for, and submission of, information 
on behalf of a Student. 


SORT INCOMING E- MAIL 


This activity represents the processes 
performed with incoming electronic mail. 
This includes distribution for processing 
within SSD and forwarding correspondence 
to other personnel, divisions, and 
departments within MCI. 


SORT INCOMING U.S. MAIL 


This activity represents the processes 
performed with incoming mail. This 
includes segregation and distribution for 
processing within SSD and forwarding 
correspondence to other departments within 
MCI. 


STUDENT ACTIVITY SERVICING 


This business function represents the 
processes required to maintain a student's 
course activity record in the database. It 
includes the enrollment, maintenance 
activities, providing status, and issuing 
material. 


STUDENT SERVICING 


This functional area represents the business 
processes required to run a successful 
Student Services Department. It includes 
the entire cycle of servicing a student from 
enrollment in a Course or Program until 
completion certification. It also includes the 
processes to service customers obtaining 
other MCI Products such as Job Aids, 
Course/Program components and materials, 
and Unit MCI Materials without enrolling in 
a Course or Program. 


VALIDATE ADMIN ACTION 


This activity represents the process of 
ensuring the student meets the requirements 
necessary to effect the requested 
administrative action for the specified 
Course or Program. 
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Activity Name 


Activity Definition 


VALIDATE ENROLLMENT 
REQUIREMENTS 


This activity represents the processes 
validating the requestor's eligibility with the 
pre-requisites of the Course or Program the 
requestor intends to enroll. 


VALIDATE MATERIAL 
REQUIREMENTS 


This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials. 


VERIFY REQUESTOR INFORMATION 


This activity verifies there is sufficient 
information available on student's request to 
begin research of transcript information. 
Information verified includes: Name, SSN, 
Address, and Dates of Service, 


WORK RETURNED UARs 


This activity represents the processes of 
reconciling student activity records based 
on input from unit Training NCOs and 
updating MCI records with the consolidated 
input. 
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Arrow Name 


Arrow Definition 


Activity Transactions/T2 


This action calls the process for Customer Activity 
Transactions. 


Admin Action/T2.4 


Calls activity to process requests for administrative action. 


Admin Credit Transaction 


Transaction occurrence triggers an update to the Student's 
record giving administrative credit for Course on system 
date. 


Admin Req Info 


Transient information collected from student and input by 
clerk. 


Admin Requests 


This is the requester's information that requests the 
administrative credit and is entered in at the PC. 


Approved 


Requester meets requirements for intended administrative 
action. 


Archived Student and Course 
Data 


Student Master File containing history of all students 
enrolled in MCI courses during the period Jan 1979 - Jan 
1989. History includes: Course Number; SSN; Last 
Name; Initials; Rank; MOS; RUC; Enrollment date; Re- 
enrollment date; Completion date; Extension (Y/N); Last 
Transaction code/date; Exams - Date/form/score for 
primary and alternate if applicable; Parent Group 
Type/Number. 


Automated Equipment 


All mechanical equipment maintained in SSD to provide 
support to SSD Operations: PC, Microfiche reader, 
Scantron, printer, PBX Telephone, etc. 


AVRS 


This represents the Conversant Automated Voice 
Response System (AVRS) which interacts with the 
database to provide a student's course status. 


Banyan E-Mail 


Mechanism that enables personnel to receive and send 
electronic correspondence. 


Change Info/T2.3 


Calls activity to process changes to a student's personal 
information. 


Corrected DP-37s 


DP-37s that had information that failed to scan properly 
or that contained data that did not pass the editing and 
were corrected. 


Course Completion Data 


This is the information necessary to register course 
completion in the database and initiate generation of 
course completion certificates. 


Course Program 
Requirements 


Course or Program requirements that determine the 
requester's eligibility to enroll/disenroll/admin credit into 
the course or program. 


Course/Program Status 
Request 


Inquiry from a requester for status on a course or 
program. 
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Arrow Name 


Arrow Definition 


Customer Input 


Customer contact with MCI in any media form: Phone, e- 
mail (includes DMS and DISN), written correspondence 
by U.S. Mail (or similar), or by walk-in. Customer input 
can be by the customer or by the unit representative 
calling on behalf of the student or by returning Unit 
Activity Reports. 


Customer Requests 


General bundle category of inquiries or other requests 
from a customer: status, information, transcript request, 
request for material, etc. 


Diploma and Letter 


Physical representation of a Diploma and a form letter of 
congratulation issued after completing all the courses in a 
program. 


Diploma Package 


Package consisting of a diploma and a form letter in an 
envelope addressed for distribution. 


Diploma Print Date 


Updates MCIAIS with date diploma is (re-)printed. 


Disapproved 


Requestor fails to meet requirements for intended 
administrative action. 


Disenrollment Transaction 


Transaction occurrence triggers an update disenrollment 
date of Students record. 


Documentation 


Bundled arrow representing the myriad of documentation 
that is distributed to the customer. 


DP-37 s 


A bubble sheet exam form that contains student and 
course information as well as the student's answers to the 
examination. 


Eligible 


Requestor passes restriction for receiving requested 
materials. 


Enroll/T2. 1 


Calls activity to process enrollment. 


Enrollment Info 


Transient data representing the information required to 
enroll a student. 


Enrollment Request 


This is information provided by the requester that will be 
keyed in to initiate an enrollment transaction. 


Enrollment Transaction 


This represents a validated enrollment creating the flags 
necessary to generate shipping documentation when 
called. 


Erroneous DP-37s 


DP-37 information on the error listing. 


- Error Codes 


Represents the informauon in the error code table. 


Error Listing File 


File, created from DP-37 data that do not pass editing, is 
the basis of OpScan error report. 


Exam Answer Key 


This arrow represents the information contained in an 
answer key. 


Exam Evaluation 


Evaluation of hand-graded exam provides a score for the 
exam to be entered into the system. 
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Arrow Name 


Arrow Definition 


Failed Exam Data 


The data that represents a student's failing score for a 
hand-graded exam, a PME exam, or an exam score that 
was obtained from the grading program with applicable 
information. 


Gen DP-37 File 


Data obtained from Student's exam (Gen DP-37) 
formatted into a file for editing and input into the Grading 
Program. 


Gen TOBESCAN File 


File, created from formatted data obtained from Student's 
exam (Gen DP-37) that passed editing, is the basis of the 
student's exam input file for the Grading Program. 


Generic DP-37s 


This is the exam form (DP-37) that has not been pre- 
formatted with any student, course and exam 
identification information but completed with the student's 
answers to the exam. 


Goodscan File 


Bundled Arrow: a File, created from formatted data 
obtained from Student's exam (Gen DP-37 and Pre- 
Slugged) that passed editing, is the student's exam input 
file for the Grading Program. 


Grading Data 


MCLAIS data used to evaluate the student's exam in the 
Grading Program. 


Hand-Graded DP-37s 


DP-37s that were rejected by the OpScanner but hand 
graded and scores entered into MCLAIS. 


Ineligible 


Requester does not pass restriction for receiving 
requested materials. 


Info Change Requests 


This is any request to change personal information on a 
student. Could be name, rank, SSN, address, component, 
etc. 


Information Changes 


This is any request to change information on a student. 
Could be an enrollment, disenrollment, or other admin 
action to change personal information or PME credit. 


Invalid Enrollment 


Enrollment request did not satisfy the requirement for 
enrollment 


Invoice Data 


Data necessary to build an invoice for mailing course or 
program components, courses or program materials, Job 
Aids or Training NCO materials. 


Laser Jet Printer 


Laser Jet printer used for printing Diplomas and 
Transcripts. 


Manual Exam Scores 


Source data that is input form hand grading exams. 


Marine Manual Resources 


Mechanism: Indicates where labor and manual processes 
occur. 



Table C-4. Arrow Dictionary. 



229 



Arrow Name 


Arrow Definition 


Material Data 


Data necessary to distinguish material that is issued as an 
MCI product. Job Aids, Exams, Course/Program 
components, and Unit Training NCO Material. 


Material Info 


Transient data that represents the MCI product material 
requested: Job Aids, Exams, Course/Program 
components, and Unit Training NCO Material. 


Material Requests 


Customer requests for material. Could be components of 
a course, program or job aid; complete (re-issue) job aid, 
course or program; or re-issue of completion certificate or 
diploma. 


Material Shipment Data 


Data concerning material shipments. 


Material Status Request 


Customer's request for status on material shipment. 


MCI Information 


Information about the course, programs and Job aids 
distributed by MCI. This covers the Course Catalog and 
MCI Procedures Manual (eventually). 


MCI Procedures Manual 


MCI's Procedures Manual which provides guidance, to 
student's and Training NCOs on the mission, functions, 
processes and protocols of conducting business with 
MCI. 


MCI SOP 


Procedures documented by each division to document 
standard operating procedures. 


MCIAIS 


The entire MCI database. 


Microfiche Reader 


Microfiche reader used to research Student and Course 
Information archived for period Jan 1979 - Jan 1989. 


New Address 


Updated information, from customer or source, used to 
make student data current. 


New Component 


Updated information, from customer or source, used to 
make student data current. 


New Name 


Updated information, from customer or source, used to 
make student data current. 


New Rank 


Updated information, from customer or source, used to 
make student data current. 


New Service Status 


Updated information, from customer or source, used to 
make student data current. 


OPS CAN Error List 


Formatted data consisting of data from: failed exams, 
exams that did not pass editing, control numbers for 
identification, and error codes or descriptors to indicate 
reason for failure. 


OpScanner 


OPSCAN 7 optical mark reader. 


OS D/PM ED Feedback 


Evaluations of courses and programs often returned with 
exam sheets following a student's completion of an 
examination. 



Table C-4. Arrow Dictionary. 



230 



Arrow Name 


Arrow Definition 


Passing Exam Data 


The data that represents a student's passing score for a 
hand-graded exam, a PME exam, or an exam score that 
was obtained from the grading program with applicable 
information. 


PBX Phone System 


AT&T Merlin telephone/voice-mail system used to 
answer phone calls to the 1-800-MCI-USMC telephone 
number. 


PC 


Personal Computer to input data and read information. 


Personal E-Mail 


Electronic mail intended to be addressed to an individual 
employee or division of MCI. 


PME Essay Evaluation 


Evaluation of hand-graded PME essay exam. 


PME Essays 




Postal Delivery 


Mechanism: represents the method of delivery of input to 
SSD. 


Pre-Slugged DP-37s 


This is the exam form (DP-37) that has been pre- 
formatted with student, course and exam identification 
information and completed with the student's answers to 
the exam. 


Process Hand Graded 
Exams/T3.2 


Call: Calls activity to process hand grade exams. 


Process Material 
Request/T2.5 


Call: calls activity to process requests for material. 


Process Status Request/T2.2 


Call: Calls activity to process status requests. 


Program Completion Data 


This is the information necessary to register program 
completion in the database and initiate generation of 
course completion certificates. 


PS DP-37 File 


Data obtained from Student's (Pre-Slugged DP-37) exam 
formatted into a file for input into the Grading Program. 


PS TOBESCAN File 


File, created from formatted data obtained from Student's 
exam (Pre-Slugged DP-37) that passed editing, is the 
basis of the student's exam input file for the Grading 
Program. 


Registrar Data 


MCIAIS data required to execute registrar processes: 
create, research and issue transcripts, create and issue 
diplomas, and accompanied form letter. 


Rejected DP-37s 


This represents the Pre-Slugged and Generic DP-37s that 
were not successfully scanned. 


Rejected Gen DP-37 s 


This represents the Generic DP-37s that were not 
successfully scanned. 


Rejected PS DP-37s 


This represents the Pre-Slugged DP-37s that were not 
successfully scanned. 
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Arrow Name 


Arrow Definition 


Reply to Customer 


A reply to the customer is in response to a request and 
usually will be replied to in the same media the request 
was submitted: enrollment not accepted, course status, 
rejected admin action request, not qualified to receive 
requested materials. There are instances when the reply 
may be implied, i.e. issuing a diploma in response to an 
exam or issuing material following enrollment are 
categories not represented by this arrow. 


Returned UARs 


Unit Activity Reports returned by a supported unit that 
has been reviewed and annotated with Training NCO 
feedback on student status and information. 


Scannable Gen DP- 37s 


This represents the DP- 37 s that can be scanned based on 
physical condition. 


Scannable PS DP-37 s 


This represents the DP-37s that can be scanned based on 
physical condition. 


Scanned DP-37s 


This represents the Pre-Slugged and Generic DP-37s that 
were successfully scanned. 


Scanned Gen DP-37s 


This represents the Generic DP-37s that were successfully 
scanned. 


Scanned PS DP-37s 


This represents the Pre-Slugged DP-37s that were 
successfully scanned. 


SSN Change 


Updated information, from customer or source, used to 
make student data current. 


Status Data 


MCIAIS data required to provide status. 


Status Request 


The customer's request for status. Status can be provided 
on a student's course, program, material shipment, 
transcript. 


Status Request on Comp 
Transcript 


The customer's request for status on a transcript. 


Student & Customer Info 


Information resident on database about students and 
customers. This includes name, rank, SSN, and address. 


Student & Unit Data 


Course and Program information regarding a student's 
status compiled by Marine Unit (RUC). 


Student and Address Data 


This arrow provides the activity with student and address 
data necessary to mail the diploma to the student 
completing the program. 


Student and Course Data 


The existing Student and Course Data on the database. 


Student Data 


Information resident on database about students. This 
includes name, grade, service component and SSN. 


Student's Course and 
Program Data 


The existing Student, Course and Program Data on a 
specific instance. 


Student's Program Data 


Program information for student's in the database. 
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Arrow Name 


Arrow Definition 


Student, Course & Exam 
Data 


The existing MCLAIS Student, Course and Exam Data. 


Transcript and Letter 


This is the transcript and the accompanying form letter 
produce in response to a transcript request. 


Transcript Course History 


Course completion history of student with accreditation 
data. 


Transcript Package 


This is the transcript and the accompanying form letter 
produced in response to a transcript request and packaged 
for mailing. 


Transcript Print Date 


System date provided when transcript is completed to 
update MCIAIS for future status requests. 


Transcript Request 


Customer's request for a transcript or SSD clerk's input 
for same. 


Transcript Request 
Information 


This is the Transcript Customer's information required to 
research and produce a transcript: Name, SSN, Address, 
Dates of Service. 


Transcript Status Request 


Customer's request for status in response to a transcript 
request or S SD clerk's input for same. 


UAR 


Unit Activity Report sent to Marine units for student 
record reconciliation. 


UAR Request 


Customer's request for a Unit Activity Report or SSD 
clerk's input for same. Request can be for a single UAR or 
group of UARs. 


Uncorrectable DP-37 s 


DP-37s that could not be corrected due to lack of 
available information provided on the bubble sheet 
submitted. 


Unscannable Gen DP -37s 


This represents the DP-37s that can not be scanned based 
on physical condition or OpScanner rejection. 


Unscannable PS DP- 37s 


This represents the DP-37s that can not be scanned based 
on physical condition or OpScanner rejection. 


Updated Student Info 


Student information updated by phone call, walk-in, e- 
mail, UAR, or U.S. mail. This can be the result of any of 
the student activity transactions include an enrollment, 
disenrollment, student's information that is changed like 
name, rank, service, component, status, etc., or course 
completion, but is directed at updating personal 
information which should be verified prior to executing 
the transaction. 


Valid Enrollment 


Transient Enrollment data that passed evaluation against 
course/program requirements. 
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Arrow Name 


Arrow Definition 


Work Returned UARs/Tl.2.2 


Call: Calls activity to process student activity servicing to 
update student records based on input provided with 
returned UAR. 


Worked UAR 


A Unit Activity Report that has been reconciled by the 
using unit and UAR processing clerk has updated the 
student records based on the reconciliation. To File. 
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Figure C-l. To Be Process Model Node Tree Diagram (TO). 
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Figure C-2. To-Be Process Model Context Diagram (T-0). 
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Figure C-3. To-Be Process Model IDEFO Diagram (TO). 
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Figure C-4. To-Be Process Model IDEFO Diagram (Tl). 
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Figure C-5. To-Be Process Model IDEFO Diagram (Tl. 1). 
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Figure C-6. To-Be Process Model IDEFO Diagram (Tl. 1.3). 
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Figure C-7. To-Be Process Model IDEFO Diagram (T 1.1. 3.1). 
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Figure C-8. To-Be Process Model IDEFO Diagram (Tl. 1.4). 
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Figure C-9. To-Be Process Model EDEFO Diagram (T1.2). 
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Figure C-10. To-Be Process Model EDEFO Diagram (T2). 
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Figure C-l 1. To-Be Process Model IDEFO Diagram (T2.1). 
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Figure C-12. To-Be Process Model IDEFO Diagram (T2. 1.2). 
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Figure C-13. To-Be Process Model IDEFO Diagram (T2.2). 
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Figure C-14. To-Be Process Model IDEFO Diagram (T2.2. 1). 
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Figure C-15. To-Be Process Model EDEFO Diagram (T2.2.2). 
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Figure C-16. To-Be Process Model EDEFO Diagram (T2.2.3). 
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Figure C-17. To-Be Process Model EDEFO Diagram (T2.3). 
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Figure C-l 8. To-Be Process Model IDEFO Diagram (T2.4). 
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Figure C-19. To-Be Process Model IDEFO Diagram (T2.4.2). 
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Figure C-20. To-Be Process Model EDEFO Diagram (T2.5). 
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Figure C-21. To-Be Process Model IDEFO Diagram (T2.5.2). 
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Figure C-22. To-Be Process Model EDEFO Diagram (T3). 
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Figure C-23. To-Be Process Model IDEFO Diagram (T3. 1). 
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Figure C-24. To-Be Process Model IDEFO Diagram (T3.1.1). 
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Figure C-25. To-Be Process Model IDEFO Diagram (T3. 1.2). 
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Figure C-26. To-Be Process Model EDEFO Diagram (T3.2). 
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Figure C-27. To-Be Process Model 1DEF0 Diagram (T3.3). 
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Figure C-28. To-Be Process Model IDEFO Diagram (T3.3.1). 
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Figure C-29. To-Be Process Model IDEFO Diagram (T3.3.2). 
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Figure C-30. To-Be Process Model IDEFO Diagram (T3.4). 
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Figure C-3 1 . To-Be Process Model IDEFO Diagram (T4). 
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Figure C-32. To-Be Process Model EDEFO Diagram (T4. 1). 
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Figure C-33. To-Be Process Model EDEFO Diagram (T4.2). 
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Figure C-34. To-Be Process Model IDEFO Diagram (T4.2. 1). 
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Figure C-35. To-Be Process Model IDEFO Diagram (T4.2.2). 

270 




Figure C-36. To-Be Process Model IDEFO Diagram (T4.2.2.1). 
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Figure C-37. To-Be Process Model EDEFO Diagram (T4.2.2.2). 
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